Blockchain-Enabled Lattice-Based Attribute-Based Searchable Encryption with Instant Revocation

Abstract

As cloud computing proliferates, outsourced data faces severe security threats, yet existing searchable encryption (SE) schemes rely on classical hardness assumptions, centralized trust authorities, and static access control, leaving critical gaps in quantum resistance, single-point-of-failure prevention, and dynamic permission management. To address these limitations, we propose BL-ABSE, a blockchain-enhanced, lattice-based attribute-based searchable encryption framework. BL-ABSE employs the Ring Learning With Errors (RLWE) problem as its security foundation and applies the Number Theoretic Transform (NTT) to reduce polynomial multiplication from $O\left(n^2\right)$ to $O(nlogn)$. To eliminate single-point trust risks, the framework further integrates a $(t,n)$ threshold key protocol across an edge-node consortium governed by Practical Byzantine Fault Tolerance (PBFT) consensus. A smart-contract-maintained on-chain revocation list enables permission withdrawal via a single blockchain transaction without re-encryption. Experimental evaluation demonstrates that commitment generation requires approximately 23 ms at $n=1024$, search latency scales linearly at roughly 29 µs per record, and revocation completes in approximately 2 s regardless of system scale. Formal security proofs under the quantum polynomial-time (QPT) adversary model reduce six security properties—index indistinguishability, query privacy, threshold key security, Byzantine fault tolerance, audit immutability, and revocation immediacy—to the hardness of RLWE and the Short Integer Solution (SIS) problems. To the best of our knowledge, BL-ABSE is the first framework to simultaneously achieve post-quantum security, attribute-based access control, decentralized key management, instant revocation, and immutable auditing within a single unified framework. We further conduct threshold parameter verification, end-to-end revocation latency decomposition, blockchain throughput stress testing, search-pattern leakage quantification, and communication/storage overhead analysis, providing a comprehensive evaluation of both performance and security trade-offs. We explicitly characterize the search-pattern leakage inherent in the deterministic commitment design as a correctness–privacy trade-off and discuss mitigation directions.

1. Introduction

With the continuous evolution of cloud computing technology, outsourced data storage has become the dominant paradigm for enterprises and individuals managing massive volumes of information. According to IBM’s Cost of a Data Breach Report 2024, the global average cost of a data breach has climbed to an all-time high of $4.88 million, with approximately 72% of breach incidents involving cloud-hosted data [1]. Highly sensitive sectors such as healthcare, financial services, and e-government administration impose the most stringent requirements on data confidentiality and regulatory compliance, yet cloud service providers may expose sensitive data through insider malicious behavior, misconfiguration, or advanced persistent threat (APT) attacks [2]. How to fully leverage cloud computing resources while preserving data confidentiality has become a core challenge in the field of information security.

Traditional encrypted storage strategies, while effective in preventing plaintext leakage, simultaneously forfeit efficient cloud-side retrieval capabilities—users who wish to search their data must download all ciphertexts, decrypt them locally, and then search, an approach whose time and bandwidth costs are unacceptable at scale [3]. Searchable Encryption (SE) mitigates this limitation by allowing users to perform keyword searches over encrypted data without first decrypting it, thereby striking a balance between confidentiality and usability [4]. Since Song et al. [5] proposed the first symmetric searchable encryption scheme in 2000, the field has developed multiple technical lines including Symmetric Searchable Encryption (SSE) [3], Public-Key Encryption with Keyword Search (PEKS) [6], and Attribute-Based Searchable Encryption (ABSE) [7]. Among these, ABSE combines fine-grained access control with ciphertext retrieval [8], making it especially suitable for multi-user collaborative data-sharing scenarios [7,9].

However, existing attribute-based searchable encryption constructions face three systemic limitations in practical deployment. First, the vast majority of these constructions base their security on the discrete logarithm problem or the bilinear Diffie–Hellman assumption [10,11]. Shor’s algorithm, however, has demonstrated that a quantum computer can break these cryptographic primitives in polynomial time [12]. In August 2024, the National Institute of Standards and Technology (NIST) formally published the first post-quantum cryptography standards FIPS 203/204/205 [13,14,15], signaling that the urgency of cryptographic migration has shifted from academic discussion to engineering deployment [16]. Second, nearly all existing approaches depend on a single trusted authority for key generation and search operations [17]. This centralized trust model is susceptible to single points of failure and key escrow risks, rendering it inadequate for the high-assurance requirements of finance, healthcare, and similar sectors [18]. Third, current permission revocation mechanisms rely heavily on key redistribution or data re-encryption [19], typically incurring latencies of hours or even days and thereby creating serious security windows of vulnerability.

In response to the post-quantum security requirement, prior research has attempted to incorporate lattice-based cryptography into searchable encryption. The FS-PEKS protocol proposed by Zhang et al. [20], a lattice-based forward-secure public-key searchable encryption construction, achieves post-quantum security but incurs $O\left(n^2\right)$ polynomial arithmetic overhead far exceeding that of traditional cryptographic approaches. Liu et al. [21] built a post-quantum-secure public-key authenticated searchable encryption construction, but it does not support multi-user access control. Shen et al. [22] designed a lattice-based multi-authority CP-ABE searchable encryption protocol that employs the KUNodes algorithm for attribute revocation; however, revocation complexity is $O(r·logN)$ and the protocol lacks a blockchain-enhanced trust model. Yang et al. [23] partially introduced NTT optimization, but only for the encryption phase and without support for dynamic permission management.

Regarding the trust model, existing approaches generally assume a single trusted key generation center. The RABAEKS protocol proposed by Cao et al. [24] and the lattice-based revocable ABE construction by Huang et al. [25] both rely on centralized authorities, resulting in an excessive concentration of privilege. Even ostensibly trustworthy service providers may introduce security vulnerabilities through insider fraud, misconfiguration, or APT attacks [2]. In recent years, several studies have integrated the blockchain with searchable encryption to enhance system trustworthiness [26,27], but these constructions are mostly based on classical cryptographic assumptions and cannot resist quantum attacks.

In terms of dynamic permission management, the attribute revocation mechanism designed by Wang et al. [28] requires key updates for all non-revoked users, with complexity proportional to the number of users. The blockchain-assisted approach of Yu et al. [26] introduces an on-chain revocation mechanism but still necessitates data re-encryption. Research by Chen et al. [29] demonstrates that the time overhead of both major revocation strategies—key update and data re-encryption—scales proportionally with system size, rendering them fundamentally infeasible for large-scale deployments. Moreover, existing solutions provide virtually no operational audit capabilities [30], making it difficult to satisfy the data access audit compliance requirements of regulations such as HIPAA and SOX [30,31].

In response to these challenges, this paper proposes BL-ABSE (Blockchain-Lattice-based Attribute-Based Searchable Encryption), a blockchain-enhanced lattice-based attribute-based searchable encryption framework. BL-ABSE organically integrates the post-quantum security of lattice-based cryptography, the fine-grained access control of attribute-based encryption, and the decentralized trust and tamper-proof auditing of the blockchain. The main contributions are as follows:

(1) Post-quantum-secure and efficient searchable encryption construction. A keyword commitment mechanism based on the RLWE problem is proposed, utilizing the Number Theoretic Transform (NTT) to reduce polynomial multiplication complexity from $O\left(n^2\right)$ to $O(nlogn)$. At the parameter $n=1024$, a 128-bit post-quantum security level is achieved, with commitment generation approximately 17× faster than a naive implementation. Security is strictly reduced to the RLWE decision problem and the Short Integer Solution (SIS) problem.

(2) Decentralized threshold key management mechanism. A $(t,n)$ threshold key protocol is designed that distributes the master key among a federation of edge nodes. User private key generation requires the collaboration of at least t nodes, verified via zero-knowledge proofs, and relies on PBFT consensus to tolerate up to $\lfloor (n-1)/3\rfloor$ Byzantine nodes, thereby eliminating single-point trust risks.

(3) Smart-contract-based instantaneous permission revocation. Blockchain smart contracts are used to maintain an on-chain revocation list. Revocation requires only a single blockchain transaction (confirmed in approximately 2 s); all subsequent search requests by a revoked user are immediately rejected without any data re-encryption or key redistribution, effectively reducing revocation latency from the hour scale to the second scale.

(4) Tamper-proof operational audit log. Critical operations including data upload, key request, search query, policy change, and permission revocation are recorded on the blockchain. Cryptographic hash chaining and distributed consensus guarantee audit immutability, facilitating compliance with requirements of regulations such as HIPAA and SOX.

(5) Rigorous formal security analysis. Under the QPT adversary model, sequential game reduction techniques are employed to formally prove that the framework satisfies six security properties: index indistinguishability, query privacy, threshold key security, Byzantine fault tolerance, audit tamper-resistance, and instantaneous revocability. All reductions are founded on the hardness of the RLWE and SIS problems.

Experimental evaluation shows that at $n=1024$, commitment generation takes approximately 23 ms, search latency is approximately 29 µs per record, and revocation latency is approximately 2 s. Compared with 13 representative approaches, to the best of our knowledge, BL-ABSE is the first searchable encryption framework to simultaneously achieve post-quantum security, attribute-based access control, decentralized key management, instantaneous revocation, and tamper-proof auditing within a single unified framework.

The remainder of this paper is organized as follows: Section 2 introduces preliminary knowledge on lattice-based cryptography, the Number Theoretic Transform, attribute-based encryption, and blockchain and smart contracts; Section 3 formalizes the problem by presenting the system model, threat model, design objectives, and formal protocol definition; Section 4 describes the protocol design in detail, including each core algorithm and smart contract construction; Section 5 conducts rigorous formal security analysis; Section 6 validates the performance of the framework through a prototype system; Section 7 concludes the paper and discusses future research directions.

2. Preliminaries

This chapter introduces the cryptographic and distributed systems foundations underlying the BL-ABSE framework, establishing the theoretical basis for the subsequent protocol design and security analysis.

2.1. Notation

This paper adopts the following notational conventions: scalars are denoted by lowercase letters (e.g., a, b), vectors by bold lowercase letters (e.g., $\mathbf{a}$, $\mathbf{b}$), and matrices by uppercase letters (e.g., A, B).

Table 1. Principal symbol descriptions.

Symbol	Description
$\lambda$	Security parameter; set to $\lambda =128$ in this paper
n	Lattice dimension, a power of 2; set to $n=1024$ in this paper
q	Prime modulus satisfying $q\equiv 1\left(\mathrm{mod}2n\right)$; set to $q=\mathrm{12,289}$ in this paper
$\sigma$	Standard deviation of the discrete Gaussian distribution; set to $\sigma =3.2$ in this paper
$R_q$	Polynomial ring, $R_q={\mathbb{Z}}_q\left[x\right]/(x^n+1)$
$(t,n)$	Threshold parameters: t is the threshold value, n is the total number of nodes
H, $H_{\mathrm{seed}}$	Hash function for keyword encoding and hash function for seed derivation

lists the principal symbols and their meanings.

2.2. Foundations of Lattice-Based Cryptography

Lattice-based cryptography is an important branch of post-quantum cryptography whose security is grounded in the computational complexity of hard problems on lattices. No quantum algorithm capable of solving these hard lattice problems in polynomial time has been discovered, making lattices an ideal foundation for constructing quantum-resistant cryptographic systems.

2.2.1. Lattice Definition and Hard Problems

Definition 1 (Lattice).

Let ${\mathbf{b}}_1,{\mathbf{b}}_2,\dots ,{\mathbf{b}}_m\in {\mathbb{R}}^n$ be m inearly independent vectors. The lattice spanned by these vectors is defined as

$$\mathcal{L}\left(\mathbf{B}\right)=\left\{{\displaystyle \sum _{i=1}^m}{z}_i{\mathbf{b}}_i:z_i\in \mathbb{Z}\right\},$$

(1)

where $\mathbf{B}=[{\mathbf{b}}_1,\dots ,{\mathbf{b}}_m]$ is called the basis matrix of the lattice.

Two fundamental hard problems exist on lattices: the Shortest Vector Problem (SVP) requires finding the shortest non-zero vector in the lattice, while the Closest Vector Problem (CVP) requires finding the lattice vector closest to a given target vector. Both problems are NP-hard, and the best known algorithms under the quantum computational model still require exponential time complexity.

2.2.2. LWE and RLWE Problems

Definition 2 (LWE Problem).

Given parameters $(n,m,q,\chi )$, the Learning With Errors (LWE) problem asks to distinguish between two distributions: (1) $(\mathbf{A},\mathbf{b})$, where $\mathbf{A}$ and $\mathbf{b}$ are sampled uniformly at random; and (2) $(\mathbf{A},\mathbf{A}\mathbf{s}+\mathbf{e})$, where $\mathbf{s}$ is a secret vector and $\mathbf{e}\leftarrow {\chi }^m$ is an error vector.

Definition 3 (RLWE Problem).

Let the polynomial ring $R_q={\mathbb{Z}}_q\left[x\right]/(x^n+1)$. The Ring Learning With Errors (RLWE) problem asks to distinguish $(a,b)$ from $(a,a·s+e)$, where $a\in R_q$ is uniformly random and $s,e$ are sampled from an error distribution. Compared with LWE, RLWE compresses the key size from $O\left(n^2\right)$ to $O\left(n\right)$ and supports $O(nlogn)$ fast polynomial multiplication via NTT.

Assumption 1 (RLWE Assumption).

For appropriately chosen parameters, the advantage of any PPT algorithm in distinguishing the above two distributions is a negligible function of the security parameter λ. The hardness of the RLWE problem can be reduced to hard problems on ideal lattices and has been adopted as a foundational assumption in NIST’s post-quantum cryptography standardization process.

2.2.3. Discrete Gaussian Distribution

Definition 4 (Discrete Gaussian Distribution).

For parameter $\sigma >0$, the discrete Gaussian distribution over the integers ${\mathcal{D}}_{\mathbb{Z},\sigma }$ is defined as follows: for any $x\in \mathbb{Z}$,

$$Pr[{\mathcal{D}}_{\mathbb{Z},\sigma }=x]\propto exp(-\pi x^2/{\sigma }^2).$$

(2)

This distribution is used to generate the error terms in the RLWE problem; the parameter $\sigma =3.2$ combined with $n=1024$ and $q=\mathrm{12,289}$ guarantees a 128-bit post-quantum security level.

2.3. Number Theoretic Transform

Definition 5 (NTT Transform).

Let q be a prime with $q\equiv 1\left(\mathrm{mod}2n\right)$, so that a primitive $2n$-th root of unity $\omega \in {\mathbb{Z}}_q^{*}$ exists. For a polynomial $a\left(x\right)={\sum }_i{a}_i{x}^i\in R_q$, the forward NTT is defined as

$${\widehat{a}}_j=\sum _i{a}_i{\omega }^{ij}modq,$$

(3)

and the inverse NTT as

$$a_i=n^{-1}\sum _j{\widehat{a}}_j{\omega }^{-ij}modq.$$

(4)

The Number Theoretic Transform (NTT) is the discrete Fourier transform over a finite field, capable of reducing the computational complexity of polynomial multiplication from $O\left(n^2\right)$ to $O(nlogn)$, and is a key technique for achieving efficient lattice-based searchable encryption in this framework.

For multiplication in $R_q$, negative wrapped convolution is employed: by introducing $\psi =\sqrt{\omega }$ and pre-multiplying and post-dividing by powers of $\psi$, efficient reduction modulo $x^n+1$ is achieved. The product of two polynomials can be computed in three steps: (1) forward NTT; (2) pointwise multiplication; (3) inverse NTT. Performance can be further improved in practice through the use of precomputed root-of-unity tables, bit-reversal permutations, and Montgomery reduction.

2.4. Attribute-Based Encryption

Definition 6 (CP-ABE Construction).

A CP-ABE construction consists of four algorithms: $\mathsf{Setup}(1^{\lambda },U)$ outputs public parameters and a master key; $\mathsf{KeyGen}(\mathsf{msk},S)$ outputs a user private key; $\mathsf{Encrypt}(\mathsf{pp},P,M)$ outputs a ciphertext; $\mathsf{Decrypt}({\mathsf{sk}}_S,CT)$ outputs the plaintext when S satisfies P. BL-ABSE employs a lattice-based CP-ABE construction whose security is based on the LWE/RLWE hardness assumption.

Attribute-Based Encryption (ABE) is a public-key encryption mechanism supporting fine-grained access control. BL-ABSE adopts Ciphertext-Policy Attribute-Based Encryption (CP-ABE), which abstracts user identities as attribute sets S and encrypts data under an access policy P; only when $P\subseteq S$ can the user decrypt the ciphertext.

2.5. Blockchain and Smart Contracts

Blockchain technology [32] provides BL-ABSE with a decentralized trust foundation and tamper-proof auditing capabilities. This framework adopts a consortium blockchain architecture, which offers the advantages of controlled access, efficient consensus, and privacy protection.

Definition 7 (Smart Contract).

A smart contract is a deterministic state transition function deployed on the blockchain:

$$\mathsf{SC}:(\mathsf{State},\mathsf{Input})\to ({\mathsf{State}}^{\prime },\mathsf{Output}),$$

(5)

whose execution is guaranteed to be deterministic and consistent by the consensus mechanism. In BL-ABSE, smart contracts fulfill three core functions: access policy management, permission revocation control, and audit log recording.

Definition 8 (Threshold Secret Sharing).

A $(t,n)$ threshold protocol splits a secret s into n shares such that: any t or more shares can reconstruct the secret s; any fewer than t shares reveal no information about s in the information-theoretic sense. BL-ABSE employs Shamir Secret Sharing to implement distributed management of the master key.

Theorem 1 (PBFT Fault Tolerance Bound).

In a PBFT system with n nodes, the maximum number of malicious nodes that can be tolerated is

$$f=\lfloor (n-1)/3\rfloor .$$

(6)

BL-ABSE is based on a PBFT consensus variant of Hyperledger Fabric; in the typical $(3,5)$ configuration, it can tolerate 1 malicious node.

2.6. Commitment Schemes

A commitment scheme is a core cryptographic primitive for searchable encryption. BL-ABSE employs an RLWE-based commitment construction to build the keyword index.

Construction 1 (RLWE Commitment).

Let the public polynomial $a\in R_q$ be deterministically generated from a seed. For a keyword w, the commitment is computed as

$$\mathsf{commit}=a·s+H\left(w\right)modq,$$

(7)

where s is deterministically derived via $H_{\mathrm{seed}}\left(w\right)$. The key design insight is that s is derived from the keyword by a public hash function rather than depending on the user’s private key; this guarantees that identical keywords produce identical commitments, which is the correctness guarantee for search matching. In terms of security, hiding is reduced to the RLWE decision problem, and binding is reduced to the SIS problem, as shown below.

Theorem 2 (Binding Property).

The RLWE commitment scheme satisfies computational binding under the SIS assumption, even when s is deterministically derived from w via $H_{\mathrm{seed}}$.

Proof. 

Suppose an adversary $\mathcal{A}$ can find two distinct keywords $w\ne w^{\prime }$ such that $\mathsf{commit}\left(w\right)=\mathsf{commit}\left(w^{\prime }\right)$, i.e.,

$$a·s+H\left(w\right)=a·s^{\prime }+H\left(w^{\prime }\right)modq,$$

(8)

where $s=\mathsf{GaussianSample}(H_{\mathrm{seed}}\left(w\right),\sigma )$ and $s^{\prime }=\mathsf{GaussianSample}(H_{\mathrm{seed}}\left(w^{\prime }\right),\sigma )$. Rearranging yields $a·(s-s^{\prime })=H\left(w^{\prime }\right)-H\left(w\right)modq$. Let $\mathbf{z}=s-s^{\prime }$; since both s and $s^{\prime }$ are drawn from discrete Gaussian distributions with parameter $\sigma =3.2$, $\mathbf{z}$ is a short polynomial with ${\parallel \mathbf{z}\parallel }_{\infty }\le O\left(\sigma \sqrt{logn}\right)$. If $w\ne w^{\prime }$, then by the collision resistance of H, $H\left(w\right)\ne H\left(w^{\prime }\right)$ with overwhelming probability, so the right-hand side is non-zero. This means $\mathcal{A}$ has found a short non-zero vector $\mathbf{z}$ satisfying $a·\mathbf{z}=H\left(w^{\prime }\right)-H\left(w\right)modq$, which constitutes a solution to an instance of the Ring-SIS problem. Under the SIS assumption, no PPT (or QPT) adversary can find such a solution with non-negligible probability.

Note that although s is deterministically derived, the adversary cannot freely choose s; selecting a keyword w determines s via the composition $H_{\mathrm{seed}}\to \mathsf{GaussianSample}$. The collision resistance of $H_{\mathrm{seed}}$ ensures that distinct keywords produce distinct seeds, and the discrete Gaussian sampling process ensures that the resulting secret polynomials are short. Therefore, the adversary’s only strategy is to find an algebraic relation among a, H, and $H_{\mathrm{seed}}$ that yields a collision, which reduces to breaking either the SIS assumption or the collision resistance of $H_{\mathrm{seed}}$.    □

Remark on Deterministic Derivation. The use of a public hash function $H_{\mathrm{seed}}$ for deriving s introduces a design trade-off: it enables non-interactive search matching (any party knowing keyword w can reproduce the commitment) at the cost of making commitments deterministic, which leaks the search pattern (identical keywords produce identical commitments). This is a fundamental correctness–privacy trade-off; the privacy implications are analyzed quantitatively in Section 5.9.

2.7. Security Model

This paper employs the leakage function framework for security modeling. The leakage function of a searchable encryption protocol $\mathcal{L}=({\mathcal{L}}_{\mathsf{Setup}},{\mathcal{L}}_{\mathsf{Encrypt}},{\mathcal{L}}_{\mathsf{Search}})$ characterizes the information leakage at each phase, including the search pattern $\mathsf{sp}\left(w\right)$ and the access pattern $\mathsf{ap}\left(w\right)$.

Definition 9 ($\mathcal{L}$-IND-INDEX Security).

A protocol satisfies index indistinguishability if for any PPT (or QPT) adversary, its advantage in the following game is negligible: the adversary submits a challenge keyword pair $(w_0^{*},w_1^{*})$, the challenger randomly selects b and returns the encrypted index of $w_b^{*}$, and the adversary’s advantage in guessing b is

$$\mathsf{Adv}=|Pr[b^{\prime }=b]-1/2|.$$

(9)

Definition 10 ($\mathcal{L}$-IND-TRAPDOOR Security).

A protocol satisfies query privacy if the adversary’s advantage in distinguishing search tokens for two different keywords is negligible.

Definition 11 (Post-Quantum Security).

The above security definitions remain valid when “PPT adversary” is replaced with “quantum polynomial-time adversary.” Since BL-ABSE is based on the RLWE and SIS problems, for which no polynomial-time quantum solving algorithm is currently known, the framework possesses post-quantum security.

3. Problem Formalization

This section provides a formal model of the BL-ABSE framework. It begins with a description of the system model, clearly identifying the participating entities and their interactions. It then analyzes the threat model, characterizing adversary capabilities and security threats. Next, it presents the design objectives. Finally, it gives the formal definition of the protocol, laying the foundation for subsequent design and analysis.

3.1. System Model

The BL-ABSE framework adopts a blockchain-enhanced edge-cloud collaborative architecture, aimed at providing efficient encrypted search services for sensitive data in distributed environments, while ensuring decentralized trust and operational auditability. The system architecture diagram is shown in Figure 1.

3.1.1. Participating Entities

The system consists of six types of entities.

Data Owner (DO): The producer and owner of data. The DO is responsible for submitting raw data and keywords to the edge node consortium for encryption processing and for specifying an access policy for each data item. The DO must register access policies on the blockchain to support subsequent dynamic updates and permission revocation.

Data User (DU): The retriever and consumer of data. The DU first applies for an attribute certificate from the attribute authority, then obtains a private key associated with its attributes through threshold collaboration among the edge node consortium. When searching, the DU generates a search token and submits a query request; the system verifies the DU’s access rights via the blockchain and returns matching results.

Edge Node Association (ENA): The core improvement of BL-ABSE. The single edge server in the original approach is replaced by an association of n edge nodes employing a $(t,n)$ threshold mechanism. The master key is split into n shares, each held by a separate node. Any t honest nodes can collaboratively complete sensitive operations such as user key generation, while any fewer than t nodes cannot obtain any information about the master key, thereby eliminating single-point-of-trust risks.

Cloud Storage Node (CSN): Provides ciphertext storage and retrieval services. BL-ABSE uses IPFS distributed storage, where ciphertexts are indexed by content-addressed hashes (CIDs). CIDs are registered on the blockchain to ensure data integrity and traceability. The CSN is assumed to be honest-but-curious—it follows protocol execution but may attempt to infer sensitive information from the data.

Blockchain Network (BCN): A newly added core infrastructure in BL-ABSE. A consortium blockchain based on Hyperledger Fabric performs three core functions: on-chain registration, verification, and updating of access policies; maintenance and immediate enforcement of user revocation lists; and tamper-proof audit logs of all critical operations.

Attribute Authority (AA): Responsible for verifying user identities and issuing attribute certificates. The AA maintains user-to-attribute mappings to ensure that only legitimate users can obtain correct attribute claims.

3.1.2. System Architecture

BL-ABSE adopts a dual-layer architecture of “encrypted search layer + blockchain enhancement layer”. The core idea is: while maintaining the efficiency of the original encrypted search mechanism, the blockchain layer systematically strengthens the trust model and dynamic management capabilities, with clear boundaries of responsibility between the two layers.

The encrypted search layer handles core cryptographic operations and contains two sub-layers: (1) Keyword search sub-layer: Based on the RLWE problem, a keyword commitment mechanism is constructed. For keyword w, the system generates commitment

$$\mathsf{commit}=a·s+H\left(w\right)modq,$$

(10)

where a is a public polynomial, s is a secret polynomial deterministically derived by the public hash function $H_{\mathrm{seed}}\left(w\right)$, and NTT optimization achieves $O(nlogn)$ complexity. (2) Access control sub-layer: Lattice-based CP-ABE is adopted for fine-grained access control, and the data key $K_{\mathrm{data}}$ is encrypted by ABE under policy P.

The blockchain enhancement layer provides decentralized trust and dynamic management capabilities, comprising three core mechanisms: (1) Decentralized key management: The master key $\mathsf{msk}$ is split via $(t,n)$ threshold secret sharing and distributed among n edge nodes; user key generation requires collaboration from at least t nodes. (2) Smart contract access control: Access policies and revocation lists are stored on the blockchain, enabling dynamic policy updates and immediate revocation via smart contracts. (3) Tamper-proof audit log: All critical operations are recorded on the blockchain, supporting retrospective tracing and accountability.

The storage architecture employs an on-chain/off-chain hybrid strategy: encrypted ciphertexts are stored on the IPFS network (off-chain), with only the content identifier CID (approximately 46 bytes) and metadata index registered on-chain. This ensures data integrity and traceability while reducing on-chain storage costs.

3.1.3. Workflow

The complete workflow of BL-ABSE includes five phases: system initialization, data upload, key request, search query, and result decryption.

Phase 1—System Initialization. The edge node consortium collaboratively generates master key shares via a Distributed Key Generation (DKG) protocol, and each node submits share verification information to the blockchain. Three smart contracts—KeyManagement, AccessControl, and AuditLog—are deployed, along with initialization of RLWE public parameters and hash functions H and $H_{\mathrm{seed}}$. This phase is executed only once at system deployment.

Phase 2—Data Upload. The DO specifies keyword w and access policy P for data M, and submits them to the edge nodes. The edge nodes: generate a data key and encrypt the data with AES-GCM; derive secret polynomial s via $H_{\mathrm{seed}}\left(w\right)$ and compute the RLWE commitment for keyword w; encrypt the data key with CP-ABE under policy P; store the encrypted data on IPFS to obtain the CID; and invoke the AccessControl contract to register the policy hash and CID.

Phase 3—Key Request. The DU applies to the AA for attribute certificate ${\mathsf{cert}}_S$, then requests a private key from the edge node consortium. After at least t nodes verify ${\mathsf{cert}}_S$, each computes a partial key and generates a zero-knowledge proof, which is submitted to the KeyManagement contract. The contract verifies all proofs and aggregates them via Lagrange interpolation to produce the complete user private key ${\mathsf{sk}}_S=(S,{\mathsf{sk}}_{\mathrm{abe},S})$.

Phase 4—Search Query. The DU derives secret polynomial s via $H_{\mathrm{seed}}\left(w\right)$ and generates search token $T_w=({\mathsf{commit}}_q,S,ts,{\sigma }_{\mathrm{user}})$ for keyword w. Since $H_{\mathrm{seed}}$ is a public parameter, the DU uses the same derivation method as the DO, ensuring the same keyword generates the same commitment. The system performs triple verification: verifying the token signature and validity period; invoking the AccessControl contract to check policy validity and revocation status; and executing RLWE commitment matching.

Phase 5—Result Decryption. The DU retrieves matching ciphertexts from IPFS, uses private key ${\mathsf{sk}}_S$ to decrypt the ABE ciphertext and obtain the data key, then uses AES-GCM decryption to recover the plaintext data. If the user’s attributes do not satisfy the policy, ABE decryption returns ⊥, ensuring enforcement of access control.

3.2. Threat Model

This section analyzes the security threats facing BL-ABSE, including adversary capabilities, specific threats, and trust assumptions.

3.2.1. Adversary Capabilities

This paper considers the following four types of adversaries, covering the full threat spectrum from external attacks to insider threats:

External Adversary (${\mathcal{A}}_{\mathbf{ext}}$): An attacker who does not participate in system operations. This adversary can eavesdrop on public communication channels and observe encrypted indices and ciphertexts, with the goal of inferring keywords or data content from public information. This paper considers external adversaries with quantum computing capabilities.

Malicious Cloud Storage Node (${\mathcal{A}}_{\mathbf{csn}}$): Modeled as honest-but-curious. It follows the protocol for storage and retrieval operations but may record metadata such as access patterns and search frequencies, attempting to infer sensitive information.

Malicious Data User (${\mathcal{A}}_{\mathbf{du}}$): A legitimate user attempting to access data beyond their authorized permissions. Attack methods include forging or tampering with attribute certificates, replaying expired search tokens, and colluding with other users to escalate privileges.

Byzantine Edge Node (${\mathcal{A}}_{\mathbf{byz}}$): Some edge nodes that are compromised or actively malicious. They may refuse to participate in key generation protocols, submit incorrect partial keys, record protocol interaction information to infer keys, or collude with other malicious nodes to reconstruct the master key.

3.2.2. Threat Analysis

Based on the adversary capabilities described above, the main security threats facing the system are shown in

Table 2. Security threat analysis.

Threat ID	Threat Description	Threat Source	Potential Impact
T1	Keyword privacy disclosure	${\mathcal{A}}_{\mathrm{ext}}$, ${\mathcal{A}}_{\mathrm{csn}}$	Adversary infers search content
T2	Data content disclosure	${\mathcal{A}}_{\mathrm{ext}}$, ${\mathcal{A}}_{\mathrm{csn}}$	Adversary obtains plaintext data
T3	Access control bypass	${\mathcal{A}}_{\mathrm{du}}$	Unauthorized access to sensitive data
T4	Master key leakage	${\mathcal{A}}_{\mathrm{byz}}$	Complete system compromise
T5	Audit log tampering	${\mathcal{A}}_{\mathrm{byz}}$, ${\mathcal{A}}_{\mathrm{du}}$	Inability to trace accountability
T6	Denial of service	${\mathcal{A}}_{\mathrm{byz}}$	Reduced system availability
T7	Quantum attack	${\mathcal{A}}_{\mathrm{ext}}$ (QPT)	Failure of classical cryptographic constructions

.

3.2.3. Trust Assumptions

Assumption 2 (Honest Majority).

At least $2n/3$ of the nodes in the edge node consortium are honest, i.e., the number of malicious nodes $f<n/3$. This is a necessary condition for the correctness of PBFT consensus. In a consortium blockchain setting, nodes are operated by pre-vetted organizations bound by commercial or legal constraints, making large-scale collusion unlikely.

Assumption 3 (Threshold Security).

Under the $(t,n)$ threshold configuration, the adversary can compromise at most $t-1$ nodes. The threshold parameter t can be configured flexibly according to security requirements; a typical configuration of $(3,5)$ allows at most 2 nodes to be compromised.

Assumption 4 (Secure Communication).

Inter-node communication is encrypted via TLS; adversaries cannot tamper with or forge inter-node messages.

Assumption 5 (Trusted Attribute Authority).

The attribute authority correctly performs identity verification and attribute issuance, and will not issue false attribute certificates to unauthorized users.

Remark 1 (AA Trust Limitation).

The trust placed in the AA represents a deliberate design choice: BL-ABSE decentralizes key management (via threshold secret sharing across the edge-node consortium) but retains a centralized attribute authority for identity-to-attribute binding. This is because attribute certification inherently requires an authoritative identity-verification process (e.g., verifying an employee’s department affiliation), which cannot be fully decentralized without introducing a separate decentralized identity layer. If the AA is compromised, it could issue fraudulent attribute certificates, potentially enabling unauthorized access. Several mitigation strategies exist: (i) deploying multiple independent AAs with cross-verification (multi-authority ABE); (ii) recording attribute issuance events on the blockchain audit log to enable post-hoc detection of anomalous issuance; (iii) requiring periodic AA re-certification with smart-contract-enforced expiration. The extension to a fully decentralized attribute management framework is an important direction for future work.

Assumption 6 (Cryptographic Assumptions).

The RLWE problem and the SIS problem remain hard under the quantum computation model; the hash functions and symmetric encryption used satisfy standard security assumptions.

3.3. Design Objectives

Based on the system model and threat analysis above, the BL-ABSE framework must satisfy the following design objectives:

Objective G1—Post-Quantum Security: The security of the framework is based on lattice hard problems (RLWE/SIS), remaining secure even against adversaries with quantum computing capabilities. The parameter selection ($n=1024$, $q=\mathrm{12,289}$) ensures a 128-bit post-quantum security level.

Objectives G2–G4: Data confidentiality ensures that unauthorized entities cannot obtain plaintext data; search privacy protection ensures that search tokens do not reveal keyword content; fine-grained access control supports attribute-based access policy definition and dynamic updates.

Objective G5—Computational Efficiency: The computational complexity for keyword commitment generation and search matching is $O(nlogn)$, and blockchain overhead is concentrated on low-frequency operations.

Objective G6—Decentralized Trust: A multi-party collaborative trust model is achieved through $(t,n)$ threshold key management and blockchain consensus, tolerating at most $\lfloor (n-1)/3\rfloor$ malicious nodes.

Objectives G7–G8: All critical operations are recorded on a tamper-proof blockchain, supporting auditing and compliance review; permission revocation is executed via blockchain transactions and takes effect within approximately 2 s, without requiring data re-encryption or key redistribution.

3.4. Formal Definition of the Protocol

This section presents the formal definition of the BL-ABSE protocol, including the algorithm interfaces, correctness, and security definitions.

3.4.1. Algorithm Definitions

Definition 12 (BL-ABSE Protocol).

A blockchain-enhanced attribute-based searchable encryption protocol, BL-ABSE, consists of the following nine probabilistic polynomial-time algorithms:

• $\mathsf{BC}\text{-}\mathsf{Setup}(1^{\lambda },n,t,U)\to (\mathsf{pp},{\left\{{\mathsf{sk}}_i\right\}}_{i\in \left[n\right]},\mathsf{BC})$: System initialization algorithm. Takes as input security parameter $\lambda$, number of edge nodes n, threshold parameter t, and attribute universe U. Outputs public parameters $\mathsf{pp}$ (including RLWE parameters, hash functions H and $H_{\mathrm{seed}}$, ABE public parameters, etc.), key shares $\left\{{\mathsf{sk}}_i\right\}$ for each node, and the initialized blockchain state $\mathsf{BC}$.
• $\mathsf{ThresholdKeyGen}(\mathsf{pp},{\left\{{\mathsf{sk}}_i\right\}}_{i\in T},S)\to {\mathsf{sk}}_S$: Threshold user key generation algorithm. Takes as input public parameters $\mathsf{pp}$, key shares of the participating node set T ($\left|T\right|\ge t$), and user attribute set S. At least t nodes collaborate; each computes a partial key and aggregates via the blockchain to output user private key ${\mathsf{sk}}_S=(S,{\mathsf{sk}}_{\mathrm{abe},S})$.
• $\mathsf{BC}\text{-}\mathsf{Encrypt}(\mathsf{pp},w,P,M)\to (\mathsf{CID},I,\mathsf{txHash})$: Data encryption algorithm. Takes as input public parameters $\mathsf{pp}$, keyword w, access policy P, and plaintext M. Derives secret polynomial s via $H_{\mathrm{seed}}\left(w\right)$ and computes a keyword commitment. Outputs IPFS content identifier $\mathsf{CID}$, searchable index I, and the blockchain transaction hash $\mathsf{txHash}$ of the policy registration.
• $\mathsf{Trapdoor}(\mathsf{pp},{\mathsf{sk}}_S,w)\to T_w$: Search token generation algorithm. Takes as input public parameters $\mathsf{pp}$, user private key ${\mathsf{sk}}_S$, and query keyword w. Derives the same secret polynomial s as the encryption side via $H_{\mathrm{seed}}\left(w\right)$, and outputs search token $T_w=({\mathsf{commit}}_q,S,ts,\mathsf{expiry},{\sigma }_{\mathrm{user}})$. Since $H_{\mathrm{seed}}$ is a public parameter, the same keyword produces the same commitment during both encryption and searching.
• $\mathsf{BC}\text{-}\mathsf{Search}(T_w,\mathsf{BC},\mathsf{DB})\to R$: Search algorithm. Takes as input search token $T_w$, blockchain state $\mathsf{BC}$, and encrypted database $\mathsf{DB}$. Performs triple verification—token validation, on-chain permission check, and commitment matching—and outputs the set of matching results R.
• $\mathsf{Decrypt}(\mathsf{pp},{\mathsf{sk}}_S,R)\to M$: Decryption algorithm. Takes as input public parameters $\mathsf{pp}$, user private key ${\mathsf{sk}}_S$, and search result set R. For each result, performs ABE decryption to obtain the data key, then AES decryption to recover the plaintext, and outputs plaintext set M.
• $\mathsf{RevokeAccess}(\mathsf{pp},\mathsf{dataId},\mathsf{userId},\mathsf{reason})\to \mathsf{txHash}$: Permission revocation algorithm. The data owner invokes this algorithm to add the specified user to the revocation list. The revocation is executed via a blockchain transaction and takes effect immediately upon confirmation.
• $\mathsf{UpdatePolicy}(\mathsf{pp},\mathsf{dataId},P_{\mathrm{new}},\mathsf{reason})\to \mathsf{txHash}$: Policy update algorithm. The data owner invokes this algorithm to update the access policy. The new policy hash replaces the old value on-chain and immediately affects all subsequent search requests.
• $\mathsf{QueryAuditLog}(\mathsf{dataId},\mathsf{timeRange})\to \mathsf{logs}$: Audit log query algorithm. Queries all operation records for the specified data item within the given time range, returning a tamper-proof list of audit logs.

3.4.2. Correctness Definition

Definition 13 (Correctness).

The BL-ABSE protocol is correct if, for all security parameters λ, all keywords $w\in {\{0,1\}}^{*}$, all access policies P, all attribute sets S satisfying $P\subseteq S$, and all plaintexts M, the following equation holds with overwhelming probability:

$$\mathsf{Decrypt}(\mathsf{pp},{\mathsf{sk}}_S,\mathsf{BC}\text{-}\mathsf{Search}(\mathsf{Trapdoor}(\mathsf{pp},{\mathsf{sk}}_S,w),\mathsf{BC},\mathsf{DB}))=M,$$

(11)

where $\mathsf{DB}$ contains the encryption result of $\mathsf{BC}\text{-}\mathsf{Encrypt}(\mathsf{pp},w,P,M)$, ${\mathsf{sk}}_S\leftarrow \mathsf{ThresholdKeyGen}(\mathsf{pp},\left\{{\mathsf{sk}}_i\right\},S)$, and the user has not been revoked. Correctness encompasses three sub-conditions: (1) Commitment matching correctness: The same keyword w derives the same secret polynomial s via the public hash function $H_{\mathrm{seed}}$, producing the same commitment. (2) ABE decryption correctness: When $P\subseteq S$, ABE.Decrypt correctly recovers the data key. (3) Threshold aggregation correctness: When $\left|T\right|\ge t$, Lagrange interpolation correctly recovers the complete private key.

3.4.3. Security Definitions

The security of BL-ABSE is characterized by the following formal definitions:

Definition 14 ($\mathcal{L}$-IND-INDEX Security).

BL-ABSE satisfies index indistinguishability if, for any PPT (or QPT) adversary $\mathcal{A}$, the adversary’s advantage in the following security game is negligible: the challenger runs $\mathsf{BC}\text{-}\mathsf{Setup}$; the adversary may issue polynomially many encryption queries and search token queries; the adversary submits a challenge keyword pair $(w_0^{*},w_1^{*})$ and policy $P^{*}$; the challenger randomly selects $b\leftarrow \{0,1\}$ and returns the encrypted index $I^{*}$ of $w_b^{*}$; the adversary outputs a guess $b^{\prime }$. The adversary’s advantage is defined as

$${\mathsf{Adv}}^{\mathrm{IND-INDEX}}\left(\mathcal{A}\right)=|Pr[b^{\prime }=b]-1/2|.$$

(12)

Definition 15 ($\mathcal{L}$-IND-TRAPDOOR Security).

BL-ABSE satisfies query privacy if, for any PPT (or QPT) adversary $\mathcal{A}$, its advantage in distinguishing search tokens $T_{w_0}$ and $T_{w_1}$ for two different keywords $w_0$, $w_1$ is negligible.

Definition 16 (Threshold Key Security).

Under the $(t,n)$ threshold configuration, for any PPT adversary $\mathcal{A}$ that compromises at most $t-1$ edge nodes, its advantage in recovering the complete master key $\mathsf{msk}$ is negligible.

Definition 17 (Byzantine Fault Tolerancey).

BL-ABSE satisfies Byzantine fault tolerance if, with at most $f=\lfloor (n-1)/3\rfloor$ malicious edge nodes, the system still guarantees: (1) Safety: honest nodes will not accept invalid key shares or transactions; (2) Liveness: legitimate requests will eventually be processed.

Definition 18 (Audit Log Tamper-Proofness).

For any PPT adversary $\mathcal{A}$, the probability of modifying historical audit logs without detection is negligible.

Definition 19 (Revocation Immediacy).

If user u is revoked access to data d at time t, then for any search request at time $t^{\prime }>t+{\Delta }_{\mathrm{confirm}}$ (where ${\Delta }_{\mathrm{confirm}}\approx 2$ seconds is the blockchain confirmation delay), user u cannot obtain data d.

4. Protocol Design

This section provides a detailed description of the concrete construction of the BL-ABSE framework. It begins with an overview of the overall design philosophy and architecture, then sequentially describes the design details of each core algorithm in the order of system initialization, threshold key generation, data encryption, search token generation, search matching, and result decryption. It then describes the dynamic permission management and audit query mechanisms, presents the smart contract design, and finally conducts correctness analysis and complexity analysis. The design of each algorithm strictly corresponds to the formal definitions in Section 3.4. The specific flow of the protocol is shown in Figure 2.

4.1. Protocol Overview

The design of BL-ABSE follows two core principles: (1) Separation of cryptographic and management layers—the cryptographic construction of the encrypted search layer is independent of the blockchain layer, ensuring that post-quantum security is unaffected by blockchain components; (2) Lightweight high-frequency operations—blockchain interactions are concentrated in low-frequency operations (system initialization, key generation, policy registration), so that high-frequency search operations only involve local computation and cached queries.

The encrypted search layer contains two sub-layers. The keyword search sub-layer exploits the hardness of the RLWE problem to construct keyword commitments: for keyword w, the system generates commitment

$$\mathsf{commit}=a·s+H\left(w\right)modq,$$

(13)

where a is a public polynomial and s is a secret polynomial deterministically derived from keyword w via hash function $H_{\mathrm{seed}}$. Using NTT optimization, the computational complexity of commitment generation is $O(nlogn)$. The access control sub-layer adopts lattice-based CP-ABE to achieve fine-grained access control, with data key $K_{\mathrm{data}}$ encrypted by ABE under policy P.

The blockchain enhancement layer contains three core mechanisms: (1) Decentralized key management—master key $\mathsf{msk}$ is distributed among n edge nodes via $(t,n)$ threshold secret sharing; (2) Smart contract access control—access policies and revocation lists are managed on-chain, supporting dynamic updates and immediate revocation; (3) Tamper-proof audit log—all critical operations are recorded on the blockchain, supporting retrospective tracing.

The following sections describe the concrete construction of each algorithm in the order of the workflow.

4.2. System Initialization

The system initialization algorithm $\mathsf{BC}\text{-}\mathsf{Setup}$ is executed collaboratively by the edge node consortium, completing four tasks: RLWE parameter generation, blockchain deployment, distributed key generation, and ABE initialization. Algorithm 1 is executed only once at system deployment, corresponding to the $\mathsf{BC}\text{-}\mathsf{Setup}$ interface in Definition 12.

Algorithm 1  $\mathsf{BC}\text{-}\mathsf{Setup}(1^{\lambda },n,t,U)$

Require: Security parameter $\lambda$, number of edge nodes n, threshold t, attribute universe U

Ensure: Public parameters $\mathsf{pp}$, node shares $\left\{{\mathsf{sk}}_i\right\}$, blockchain state $\mathsf{BC}$

1:   RLWE parameter selection: $n_{\mathrm{lattice}}\leftarrow 1024$, $q\leftarrow 12,289$, $\sigma \leftarrow 3.2$, $B\leftarrow 40$   2:   ${\mathsf{seed}}_A\stackrel{\$}{\leftarrow }{\{0,1\}}^{256}$   3:   $a\leftarrow \mathsf{ExpandSeed}\left({\mathsf{seed}}_A\right)\in R_q$   4:   $\widehat{a}\leftarrow \mathsf{NTT}\left(a\right)$   5:   $\mathsf{BC}\leftarrow \mathsf{InitFabricNetwork}\left(n\right)$   6:   $\mathsf{ConfigurePBFT}(\mathsf{blockTime}=2\mathrm{s})$   7:   ${\mathsf{addr}}_{\mathsf{KM}}\leftarrow \mathsf{DeployContract}\left(\mathsf{KeyManagement}\right)$   8:   ${\mathsf{addr}}_{\mathsf{AC}}\leftarrow \mathsf{DeployContract}\left(\mathsf{AccessControl}\right)$   9:   ${\mathsf{addr}}_{\mathsf{AL}}\leftarrow \mathsf{DeployContract}\left(\mathsf{AuditLog}\right)$ 10:   for  $i=1$  to  n  do 11:        $f_i\left(x\right)\stackrel{\$}{\leftarrow }{\mathbb{Z}}_q\left[x\right]$, $deg\left(f_i\right)=t-1$ 12:        for $j=1$ to n do 13:             $s_{i,j}\leftarrow f_i\left(j\right)$ 14:             $\mathsf{SecureSend}({\mathsf{EN}}_i\to {\mathsf{EN}}_j,s_{i,j})$ 15:       end for 16:       for $j=1$ to n do 17:             ${\mathsf{sk}}_j\leftarrow {\sum }_i{s}_{i,j}modq$ 18:             $C_j\leftarrow g^{{\mathsf{sk}}_j}$ 19:             $\mathsf{KeyManagement.registerNode}({\mathsf{EN}}_j.\mathsf{addr},C_j)$ 20:        end for 21:   end for 22:   $({\mathsf{pp}}_{\mathsf{abe}},\left\{{\mathsf{msk}}_{\mathsf{abe},i}\right\})\leftarrow \mathsf{DistributedABE.Setup}(1^{\lambda },U,t,n)$ 23:   $\mathsf{pp}\leftarrow (n,q,\sigma ,B,H,H_{\mathrm{seed}},a,\widehat{a},{\mathsf{pp}}_{\mathsf{abe}},\mathsf{contracts})$ 24:   return  $(\mathsf{pp},\left\{{\mathsf{sk}}_i\right\},\mathsf{BC})$

Design Notes. (1) Parameter selection: Lattice dimension $n=1024$ ensures a 128-bit post-quantum security level; prime $q=\mathrm{12,289}$ satisfies the NTT requirement ($q\equiv 1mod2n$) and is the smallest prime satisfying this condition, helping to reduce computational overhead; standard deviation $\sigma =3.2$ achieves a balance between security and correctness; threshold $B=40$ is determined by noise analysis, as detailed in Section 4.11. (2) Precomputation optimization: Step 4 precomputes the NTT representation of a and stores it; all subsequent commitment generation uses this representation directly, avoiding repeated forward NTT transforms. (3) DKG protocol: Pedersen DKG is employed; each node generates a random degree-$(t-1)$ polynomial and distributes shares to other nodes, so that each node’s final share ${\mathsf{sk}}_j$ is the sum of evaluations of all polynomials at point j. The public verification commitment $C_j=g^{{\mathsf{sk}}_j}$ is registered on-chain to support subsequent zero-knowledge proof verification. (4) Hash function configuration: The public parameters include two independent hash functions $H:{\{0,1\}}^{*}\to R_q$ (for keyword encoding) and $H_{\mathrm{seed}}:{\{0,1\}}^{*}\to {\{0,1\}}^{256}$ (for deriving Gaussian sampling seeds); their independence is key to the security proof.

Parameter Security Strength Analysis. For the parameters $(n=1024,q=\mathrm{12,289}$, $\sigma =3.2$), we estimate the concrete security level using standard lattice-estimator methodology. The root Hermite factor is $\delta ={(q/\sigma )}^{1/n}\approx 1.0082$, which corresponds to a BKZ block size $\beta \approx 456$ under the classical Core-SVP model ($\mathrm{cost}\approx 2^{0.292\beta }\approx 2^{133}$) and $\beta \approx 456$ under the quantum sieving model ($\mathrm{cost}\approx 2^{0.265\beta }\approx 2^{121}$). Both estimates exceed the 128-bit classical (respectively, 120-bit quantum) security threshold required for NIST Level 1.

Comparison with NIST FIPS 203 (ML-KEM). The NIST ML-KEM-768 standard [13] uses parameters $n=256$, $k=3$, $q=3329$ in a Module-LWE setting, yielding an effective ring dimension of 768 and achieving NIST Level 3 (≥192-bit security). BL-ABSE uses a different ring structure ($R_q={\mathbb{Z}}_{12,289}\left[x\right]/(x^{1024}+1)$, ideal-lattice RLWE) with a larger ring dimension ($n=1024$) and larger modulus ($q=\mathrm{12,289}$ vs. 3329). The larger modulus is required by the NTT constraint $q\equiv 1\left(\mathrm{mod}2n\right)$ and the commitment arithmetic. Despite the structural differences, both parameter sets derive their hardness from the same family of lattice problems (RLWE → approximate SVP on ideal lattices), validating the post-quantum security foundation of BL-ABSE.

4.3. Threshold User Key Generation

User key generation requires collaboration from at least t edge nodes; a single node cannot independently generate a valid key. This design eliminates the reliance on a single key generation center in traditional approaches. Algorithm 2 corresponds to the $\mathsf{ThresholdKeyGen}$ interface in Definition 12.

Algorithm 2  $\mathsf{ThresholdKeyGen}(\mathsf{pp},S,{\left\{{\mathsf{EN}}_i\right\}}_{i\in T})$

Require: Public parameters $\mathsf{pp}$, user attribute set S, participating node set T with $\left|T\right|\ge t$

Ensure: User private key ${\mathsf{sk}}_S$

1:   $\mathsf{userId}\leftarrow H\left(\mathsf{DU.pubKey}\right)$, $\mathsf{attrHash}\leftarrow H\left(S\right)$   2:   $\mathsf{requestId}\leftarrow \mathsf{KeyManagement.requestKeyGen}(\mathsf{userId},\mathsf{attrHash},\mathsf{nonce})$   3:   for each ${\mathsf{EN}}_i\in T$ do   4:       if $\mathsf{VerifyAttributeCert}(S,\mathsf{AA.cert})$ then   5:            ${\mathsf{sk}}_{\mathsf{abe},S}^{\left(i\right)}\leftarrow \mathsf{ABE.PartialKeyGen}({\mathsf{msk}}_{\mathsf{abe},i},S)$   6:            ${\pi }_i\leftarrow \mathsf{GenerateZKProof}({\mathsf{sk}}_{\mathsf{abe},S}^{\left(i\right)},C_i)$   7:            $\mathsf{KeyManagement.submitPartialKey}(\mathsf{requestId},i,\mathsf{Enc}\left({\mathsf{sk}}^{\left(i\right)}\right),{\pi }_i)$   8:       end if   9:   end for 10:   if  $\mathsf{KeyManagement.verifyAllProofs}\left(\mathsf{requestId}\right)$  then 11:        ${\lambda }_i\leftarrow \mathsf{LagrangeCoefficients}\left(T\right)$ 12:        ${\mathsf{sk}}_{\mathsf{abe},S}\leftarrow {\sum }_{i\in T}{\lambda }_i·{\mathsf{sk}}_{\mathsf{abe},S}^{\left(i\right)}$ 13:   end if 14:   ${\mathsf{sk}}_S\leftarrow (S,{\mathsf{sk}}_{\mathsf{abe},S})$ 15:   $\mathsf{AuditLog.emit}(\mathsf{KeyGeneration},\mathsf{userId},\mathsf{attrHash},T,\mathsf{ts})$ 16:   return  ${\mathsf{sk}}_S$

Design Notes. (1) Zero-knowledge proofs: In Step 6, each node generates a zero-knowledge proof ${\pi }_i$, proving that its submitted partial key was correctly computed from its held share ${\mathsf{sk}}_i$, without leaking ${\mathsf{sk}}_i$ itself. This prevents Byzantine nodes from submitting incorrect shares to corrupt key correctness. (2) Encrypted transmission: In Step 7, partial keys are submitted to the chain in encrypted form, decryptable only by the requesting user, preventing other nodes or on-chain observers from obtaining partial keys. (3) Simplified private key structure: Unlike traditional approaches, the user private key ${\mathsf{sk}}_S$ in this framework consists only of attribute set S and ABE private key ${\mathsf{sk}}_{\mathrm{abe},S}$, without any user-specific PRF keys. This is because the deterministic derivation of keyword commitments relies entirely on the public-parameter hash function $H_{\mathrm{seed}}$, not on user-private keys, thereby ensuring that different users generate the same search commitment for the same keyword, enabling correct search matching.

4.4. Data Encryption

The data encryption algorithm $\mathsf{BC}\text{-}\mathsf{Encrypt}$ is one of the core algorithms of BL-ABSE. It executes five steps: keyword commitment generation (NTT-optimized), ABE encryption, symmetric encryption, IPFS storage, and on-chain registration. Algorithm 3 corresponds to the $\mathsf{BC}\text{-}\mathsf{Encrypt}$ interface in Definition 12.

Algorithm 3  $\mathsf{BC}\text{-}\mathsf{Encrypt}(\mathsf{pp},w,P,M)$

Require: Public parameters $\mathsf{pp}$, keyword w, access policy P, plaintext M

Ensure:$\mathsf{CID}$, index I, transaction hash $\mathsf{txHash}$

1:   ${\mathsf{seed}}_c\leftarrow H_{\mathrm{seed}}\left(w\right)$   2:   $s\leftarrow \mathsf{GaussianSample}({\mathsf{seed}}_c,\sigma )\in R_q$   3:   $e_w\leftarrow H\left(w\right)\in R_q$   4:   $\widehat{s}\leftarrow \mathsf{NTT}(s·\psi )$   5:   $\widehat{c}\leftarrow \widehat{a}\odot \widehat{s}$   6:   $c\leftarrow \mathsf{INTT}\left(\widehat{c}\right)·{\psi }^{-1}$   7:   $\mathsf{commit}\leftarrow c+e_{w}modq$   8:   $K_{\mathrm{data}}\stackrel{\$}{\leftarrow }{\{0,1\}}^{256}$   9:   $C_{\mathsf{abe}}\leftarrow \mathsf{ABE.Encrypt}({\mathsf{pp}}_{\mathsf{abe}},P,K_{\mathrm{data}})$ 10:   $\mathsf{nonce}\stackrel{\$}{\leftarrow }{\{0,1\}}^{96}$ 11:   $C\leftarrow \mathsf{AES}\text{-}\mathsf{GCM.Encrypt}(K_{\mathrm{data}},\mathsf{nonce},M)$ 12:   $\mathsf{data}\_\mathsf{blob}\leftarrow \mathsf{Serialize}(C,C_{\mathsf{abe}},\mathsf{nonce})$ 13:   $\mathsf{CID}\leftarrow \mathsf{IPFS.Add}(\mathsf{data}\_\mathsf{blob})$ 14:   $\mathsf{dataId}\leftarrow H(\mathsf{CID}\parallel \mathsf{owner}\parallel \mathsf{ts})$ 15:   $\mathsf{policyHash}\leftarrow H\left(P\right)$ 16:   $\mathsf{txHash}\leftarrow \mathsf{AccessControl.registerPolicy}(\mathsf{dataId},\mathsf{policyHash},\mathsf{expireTime},\mathsf{CID})$ 17:   $\mathsf{AuditLog.emit}(\mathsf{DataUpload},\mathsf{dataId},\mathsf{owner},\mathsf{policyHash},\mathsf{CID},\mathsf{ts})$ 18:   $I\leftarrow (\mathsf{commit},\mathsf{policyHash},\mathsf{CID},\mathsf{ts})$ 19:   return  $(\mathsf{CID},I,\mathsf{txHash})$

NTT Optimization Details. Steps 1–7 are the efficiency core of this framework. The naive implementation of polynomial multiplication $a·s$ over $R_q={\mathbb{Z}}_q\left[x\right]/(x^n+1)$ requires $O\left(n^2\right)$ modular multiplications. BL-ABSE uses NTT optimization based on the negative wrapped convolution to reduce this to $O(nlogn)$: (1) Pre-multiply by $\psi$ (Step 4): Introduce the $2n$-th primitive root of unity $\psi$ (satisfying ${\psi }^2=\omega$) and multiply the coefficients $s_i$ of polynomial s by ${\psi }^i$. This preprocessing transforms the mod-$(x^n+1)$ convolution into a standard cyclic convolution, making the NTT directly applicable. (2) Pointwise multiplication in the NTT domain (Step 5): In the NTT domain, polynomial multiplication degenerates to n independent modular multiplications, each requiring $O\left(1\right)$ time. Since $\widehat{a}$ was precomputed during system initialization (Algorithm 1, Step 4), only the NTT of s and the pointwise multiplication need to be computed here. (3) Inverse transform and post-divide (Step 6): Apply INTT to the pointwise product to obtain the convolution result, then divide by powers of $\psi$ to recover the original coordinates.

Deterministic Commitment Mechanism. The key design in this construction is Step 1: the seed ${\mathsf{seed}}_c$ is derived directly from keyword w by the public hash function $H_{\mathrm{seed}}$, rather than relying on user-private keys. This design ensures: (i) the same keyword w, regardless of who encrypts or searches, always produces the same seed ${\mathsf{seed}}_c=H_{\mathrm{seed}}\left(w\right)$; (ii) which in turn derives the same secret polynomial s; (iii) ultimately producing the same commitment. This is the fundamental guarantee of search matching correctness.

On-chain/Off-chain Separation Design. Encrypted data are stored on IPFS (off-chain); only the CID (46 bytes), policy hash (32 bytes), and a small amount of metadata are stored on-chain (Steps 14–16). The rationale is: (1) On-chain storage costs far exceed off-chain costs, making it uneconomical to put large amounts of ciphertext on-chain; (2) IPFS’s content-addressing mechanism naturally ensures data integrity—the CID is a cryptographic hash of the data, and tampering with the data will change the CID; (3) Once the CID is registered on-chain, it is immutable, ensuring data traceability.

4.5. Search Token Generation

The search token generation algorithm $\mathsf{Trapdoor}$ is executed locally by the data user. It generates a search token containing a commitment, attributes, timestamp, and signature. Token generation does not involve blockchain interaction, ensuring low-latency search requests. Algorithm 4 corresponds to the $\mathsf{Trapdoor}$ interface in Definition 12.

Algorithm 4  $\mathsf{Trapdoor}(\mathsf{pp},{\mathsf{sk}}_S,w)$

Require: Public parameters $\mathsf{pp}$, user private key ${\mathsf{sk}}_S=(S,{\mathsf{sk}}_{\mathsf{abe},S})$, query keyword w

Ensure: Search token $T_w$

1:   ${\mathsf{seed}}_c\leftarrow H_{\mathrm{seed}}\left(w\right)$   2:   $s\leftarrow \mathsf{GaussianSample}({\mathsf{seed}}_c,\sigma )$   3:   ${\mathsf{commit}}_q\leftarrow \mathsf{NTT}\_\mathsf{Multiply}(a,s)+H\left(w\right)modq$   4:   $\mathsf{ts}\leftarrow \mathsf{CurrentTimestamp}\left(\right)$   5:   $\mathsf{expiry}\leftarrow \mathsf{ts}+\mathsf{TOKEN}\_\mathsf{VALIDITY}$   6:   $\mathsf{msg}\leftarrow ({\mathsf{commit}}_q\parallel S\parallel \mathsf{ts}\parallel \mathsf{expiry})$   7:   ${\sigma }_{\mathsf{user}}\leftarrow \mathsf{Sign}(\mathsf{DU.privKey},\mathsf{msg})$   8:   $T_w\leftarrow ({\mathsf{commit}}_q,S,\mathsf{ts},\mathsf{expiry},{\sigma }_{\mathsf{user}})$   9:   return  $T_w$

Design Notes. (1) Matching principle: The computation in Steps 1–3 is identical to Steps 1–7 of Algorithm 3—the same keyword w derives the same seed ${\mathsf{seed}}_c$ via the public hash function $H_{\mathrm{seed}}$, then generates the same secret polynomial s and the same commitment ${\mathsf{commit}}_q$. This is the basis for search matching correctness. Since seed derivation depends only on public parameter $H_{\mathrm{seed}}$ and keyword w, and not on user identity, any authorized user who knows the keyword can generate the correct search token. (2) Anti-replay mechanism: The token contains timestamp $ts$ and validity period $\mathsf{expiry}$ (Steps 4–5); expired tokens will be rejected by the search algorithm. User signature ${\sigma }_{\mathrm{user}}$ (Step 7) binds the token content to user identity, preventing tampering and forgery. (3) Efficiency characteristics: Token generation is executed entirely locally by the user, requiring no network communication or blockchain interaction; latency is determined only by a single NTT polynomial multiplication and a single signature computation.

4.6. Search Matching

The search algorithm $\mathsf{BC}\text{-}\mathsf{Search}$ is the core of BL-ABSE’s secure search. It performs triple verification: token validation, on-chain permission check, and commitment matching. Only data items that pass all verification steps are added to the result set. Algorithm 5 corresponds to the $\mathsf{BC}\text{-}\mathsf{Search}$ interface in Definition 12.

Triple Verification Mechanism Details. The search process of BL-ABSE fuses the cryptographic matching of traditional searchable encryption with dynamic permission checking on the blockchain, forming triple verification: (1) On-chain policy verification (Steps 5–6): Checks whether the data’s access policy is still valid. A policy may be invalidated due to expiry or being explicitly disabled by the data owner. This check ensures that invalidated policies are no longer used. (2) On-chain revocation check (Step 7): Queries the revocation list on the blockchain to check whether the current user has been revoked access to the data. This is the key step for achieving immediate revocation. (3) RLWE commitment matching (Steps 9–13): This is the core cryptographic matching step. The difference between the stored commitment ${\mathsf{commit}}_i$ and the query commitment ${\mathsf{commit}}_q$ is computed, and the difference coefficients are mapped to the interval $[-q/2,q/2]$ via centered reduction (Steps 10–11). The squared Euclidean distance is then computed. If the distance is less than threshold B, a match is declared.

Algorithm 5  $\mathsf{BC}\text{-}\mathsf{Search}(T_w,\mathsf{BC},\mathsf{DB})$

Require: Search token $T_w$, blockchain state $\mathsf{BC}$, encrypted database $\mathsf{DB}$

Ensure: Set of matching results R

1: if  $\mathsf{CurrentTimestamp}\left(\right)>\mathsf{expiry}$  then   2:       return $\mathsf{REJECT}$   3: end if   4: if  $\neg \mathsf{VerifySignature}(\mathsf{DU.pubKey},\mathsf{msg},{\sigma }_{\mathsf{user}})$  then   5:       return $\mathsf{REJECT}$   6: end if   7: $R\leftarrow \left\{\right\}$, $\mathsf{userId}\leftarrow H\left(\mathsf{DU.pubKey}\right)$   8: for each $(I_i,{\mathsf{CID}}_i)\in \mathsf{DB}$ do   9:       $\mathsf{policy}\leftarrow \mathsf{AccessControl.getPolicy}\left({\mathsf{dataId}}_i\right)$ 10:       if $\mathsf{policy.expireTime}<\mathsf{now}$ or $\neg \mathsf{policy.isActive}$ then 11:            continue 12:       end if 13:       if $\mathsf{AccessControl.isRevoked}({\mathsf{dataId}}_i,\mathsf{userId})$ then 14:            continue 15:       end if 16:       if $P_i\not\subset S$ then 17:            continue 18:       end if 19:       $\mathsf{diff}\leftarrow ({\mathsf{commit}}_i-{\mathsf{commit}}_q)modq$ 20:       for $j=0$ to $n-1$ do 21:            if $\mathsf{diff}\left[j\right]>q/2$ then 22:                 $\mathsf{diff}\left[j\right]\leftarrow \mathsf{diff}\left[j\right]-q$ 23:            end if 24:       end for 25:       $\mathsf{dist}\leftarrow {\sum }_j\mathsf{diff}{\left[j\right]}^2$ 26:       if $\mathsf{dist}\le B$ then 27:            $R\leftarrow R\cup \left\{{\mathsf{CID}}_i\right\}$ 28:       end if 29: end for 30: $\mathsf{AuditLog.emit}(\mathsf{SearchQuery},\mathsf{queryId},\mathsf{userId},H\left({\mathsf{commit}}_q\right),|R|,\mathsf{ts})$ 31: return  R

Correctness Analysis of Matching. When the search keyword w matches the data keyword, since both sides use the same public hash function $H_{\mathrm{seed}}\left(w\right)$ to produce the same seed ${\mathsf{seed}}_c$, and subsequently derive the same secret polynomial s, we have ${\mathsf{commit}}_i-{\mathsf{commit}}_q=(a·s+H\left(w\right))-(a·s+H\left(w\right))=0$, so $\mathsf{dist}=0\le B$ and the match succeeds. When keywords differ, $H\left(w\right)$ and $H\left(w^{\prime }\right)$ are independently random polynomials, and the norm of the difference exceeds B with overwhelming probability, causing the match to fail.

On-chain Query Optimization. To avoid the latency overhead of on-chain queries with every search, BL-ABSE employs a local cache + event subscription mechanism: edge nodes cache policies and revocation lists locally and update the cache in real time by subscribing to blockchain events. When a policy change or revocation operation triggers a blockchain event, the cache is updated within the next block confirmation time (approximately 2 s). This reduces the 15 ms latency of on-chain queries to microsecond-level memory access.

4.7. Result Decryption

The decryption algorithm retrieves matching ciphertexts from IPFS and sequentially performs ABE decryption and AES decryption. Algorithm 6 corresponds to the $\mathsf{Decrypt}$ interface in Definition 12.

Algorithm 6  $\mathsf{Decrypt}(\mathsf{pp},{\mathsf{sk}}_S,R)$

Require: Public parameters $\mathsf{pp}$, user private key ${\mathsf{sk}}_S$, result set R

Ensure: Plaintext set M

1:   $M\leftarrow \left\{\right\}$   2:   for each $\mathsf{CID}\in R$ do   3:         $(C,C_{\mathsf{abe}},\mathsf{nonce})\leftarrow \mathsf{Deserialize}\left(\mathsf{IPFS.Get}\left(\mathsf{CID}\right)\right)$   4:         $K_{\mathrm{data}}\leftarrow \mathsf{ABE.Decrypt}({\mathsf{pp}}_{\mathsf{abe}},{\mathsf{sk}}_{\mathsf{abe},S},C_{\mathsf{abe}})$   5:         if $K_{\mathrm{data}}=\perp$ then   6:              continue   7:         end if   8:         $m\leftarrow \mathsf{AES}\text{-}\mathsf{GCM.Decrypt}(K_{\mathrm{data}},\mathsf{nonce},C)$   9:         if $m\ne \perp$ then 10:              $M\leftarrow M\cup \left\{m\right\}$ 11:         end if 12:         $\mathsf{AuditLog.emit}(\mathsf{DataAccess},\mathsf{CID},\mathsf{userId},\mathsf{ts})$ 13:   end for 14:   return  M

Design Notes. (1) Two-layer decryption: The ABE decryption in Step 4 recovers data key $K_{\mathrm{data}}$; the AES-GCM decryption in Step 6 recovers plaintext M. The two-layer separation means that access control (guaranteed by ABE) and data encryption (guaranteed by AES) operate independently, with their security not affecting each other. (2) Integrity verification: AES-GCM provides authenticated encryption; the decryption process in Step 6 simultaneously verifies ciphertext integrity. If the ciphertext has been tampered with, decryption returns ⊥, effectively preventing ciphertext substitution attacks. (3) Audit logging: Every data access is recorded on-chain (Step 8), including the accessor, timestamp, and data identifier, supporting retrospective tracing.

4.8. Dynamic Permission Management

Dynamic permission management is an important improvement of BL-ABSE over traditional ABSE constructions. This section describes two algorithms—permission revocation and policy update—both of which take effect immediately through blockchain transactions.

4.8.1. Permission Revocation

The permission revocation algorithm allows the data owner to immediately revoke a specific user’s access rights without re-encryption. Algorithm 7 corresponds to the $\mathsf{RevokeAccess}$ interface in Definition 12.

Algorithm 7  $\mathsf{RevokeAccess}(\mathsf{pp},\mathsf{dataId},\mathsf{userId},\mathsf{reason})$

Require: Data ID $\mathsf{dataId}$, revoked user ID $\mathsf{userId}$, revocation reason $\mathsf{reason}$

Ensure: Transaction hash $\mathsf{txHash}$

1:   $\mathsf{caller}\leftarrow \mathsf{msg.sender}$   2:   $\mathsf{policy}\leftarrow \mathsf{AccessControl.getPolicy}\left(\mathsf{dataId}\right)$   3:   require($\mathsf{caller}==\mathsf{policy.owner}$)   4:   $\mathsf{txHash}\leftarrow \mathsf{AccessControl.revokeAccess}(\mathsf{dataId},\mathsf{userId})$   5:   $\mathsf{AuditLog.emit}(\mathsf{Revocation},\mathsf{dataId},\mathsf{userId},\mathsf{caller},\mathsf{reason},\mathsf{ts})$   6:   return  $\mathsf{txHash}$

Immediate Effect Mechanism. Once the revocation transaction is submitted to the blockchain and confirmed by PBFT consensus (approximately 2 s), it is written into the tamper-proof ledger. Since $\mathsf{BC}\text{-}\mathsf{Search}$ checks the revocation list on every search (Algorithm 5, Step 7), all subsequent search requests from the revoked user are immediately rejected. Compared to traditional approaches that require re-encrypting all related data (which may take hours), the on-chain revocation list mechanism reduces the revocation delay from hours to seconds, with no re-encryption operations required.

4.8.2. Policy Update

The policy update algorithm allows the data owner to dynamically modify access policies. Algorithm 8 corresponds to the $\mathsf{UpdatePolicy}$ interface in Definition 12.

Algorithm 8  $\mathsf{UpdatePolicy}(\mathsf{pp},\mathsf{dataId},P_{\mathsf{new}},\mathsf{reason})$

Require: Data ID $\mathsf{dataId}$, new policy $P_{\mathsf{new}}$, update reason $\mathsf{reason}$

Ensure: Transaction hash $\mathsf{txHash}$

1:   $\mathsf{caller}\leftarrow \mathsf{msg.sender}$   2:   $\mathsf{policy}\leftarrow \mathsf{AccessControl.getPolicy}\left(\mathsf{dataId}\right)$   3:   require($\mathsf{caller}==\mathsf{policy.owner}$)   4:   $\mathsf{oldHash}\leftarrow \mathsf{policy.policyHash}$   5:   $\mathsf{newHash}\leftarrow H\left(P_{\mathsf{new}}\right)$   6:   $\mathsf{txHash}\leftarrow \mathsf{AccessControl.updatePolicy}(\mathsf{dataId},\mathsf{newHash})$   7:   $\mathsf{AuditLog.emit}(\mathsf{PolicyUpdate},\mathsf{dataId},\mathsf{oldHash},\mathsf{newHash},\mathsf{reason},\mathsf{ts})$   8:   return  $\mathsf{txHash}$

Design Notes and Limitations. On-chain policy updates only replace the policy hash (Step 6), immediately affecting policy matching verification during subsequent searches.

4.9. Audit Query

The audit query algorithm allows authorized users to query the complete operation history, supporting compliance review and security incident investigation. Algorithm 9 corresponds to the $\mathsf{QueryAuditLog}$ interface in Definition 12.

Algorithm 9  $\mathsf{QueryAuditLog}(\mathsf{dataId},\mathsf{timeRange},\mathsf{requester})$

Require: Data ID $\mathsf{dataId}$, time range $(\mathsf{start},\mathsf{end})$, requester $\mathsf{requester}$

Ensure: Audit log list $\mathsf{logs}$

1:   $\mathsf{isOwner}\leftarrow (\mathsf{requester}==\mathsf{AccessControl.getPolicy}(\mathsf{dataId}).\mathsf{owner})$   2:   $\mathsf{isAuditor}\leftarrow \mathsf{AuditLog.isAuthorizedAuditor}\left(\mathsf{requester}\right)$   3:   require($\mathsf{isOwner}$ or $\mathsf{isAuditor}$)   4:   $\mathsf{events}\leftarrow \mathsf{AuditLog.queryEvents}(\mathsf{dataId},\mathsf{start},\mathsf{end})$   5:   $\mathsf{logs}\leftarrow \left[\right]$   6:   for each $\mathsf{event}\in \mathsf{events}$ do   7:         $\mathsf{log}\leftarrow \{\mathsf{type},\mathsf{timestamp},\mathsf{actor},\mathsf{details},\mathsf{txHash},\mathsf{blockNum}\}$   8:         $\mathsf{logs.append}\left(\mathsf{log}\right)$   9:     end for 10:   return  $\mathsf{logs}$

BL-ABSE records six types of audit events: DataUpload, KeyGeneration, SearchQuery, DataAccess, Revocation, and PolicyUpdate. Each log entry contains the operation type, timestamp, actor identity, detailed information, and blockchain transaction hash, supporting complete operation tracing. Audit logs are stored on the blockchain, with their tamper-proofness guaranteed by the consensus mechanism.

4.10. Smart Contract Design

BL-ABSE deploys three core smart contracts, responsible for key management, access control, and audit logging, respectively. This section presents the key data structures and interface designs for each contract.

4.10.1. AccessControl Contract

The AccessControl contract is the core of BL-ABSE’s on-chain governance, managing the lifecycle of access policies and the user revocation list.

Core Data Structures. The Policy struct contains: policyHash (policy hash, bytes32), owner (data owner address), createTime and expireTime (creation and expiration times), isActive (validity flag), ipfsCid (IPFS content identifier), and a revokedUsers mapping (user revocation status).

Core Interfaces. (1) registerPolicy (dataId, policyHash, expireTime, CID): Registers a new policy, called only during data upload. (2) verifyAccess (dataId, userId, attrHash): Verifies whether a user is authorized to access the specified data. (3) revokeAccess (dataId, userId): Adds a user to the revocation list. (4) isRevoked (dataId, userId): Queries a user’s revocation status. (5) updatePolicy (dataId, newPolicyHash): Updates the policy hash.

4.10.2. KeyManagement Contract

The KeyManagement contract coordinates the on-chain process of threshold key generation, ensuring the correctness of partial keys submitted by each node.

Core Interfaces. (1) registerNode(nodeAddr, commitment): Registers an edge node and its public verification commitment. (2) requestKeyGen (userId, attrHash, nonce): The user initiates a key generation request. (3) submitPartialKey (requestId, nodeId, encPartialKey, proof): A node submits an encrypted partial key and a zero-knowledge proof. (4) verifyAllProofs (requestId): Verifies all submitted zero-knowledge proofs; if all pass, triggers key aggregation.

4.10.3. AuditLog Contract

The AuditLog contract records all critical operations in the system, providing a tamper-proof audit trail.

Core Interfaces. (1) emit (eventType, …): Emits an audit event, automatically attaching a timestamp and transaction hash. (2) queryEvents (dataId, startTime, endTime): Queries audit events by data ID and time range. (3) isAuthorizedAuditor (addr): Verifies whether the requester has audit privileges. The contract uses Hyperledger Fabric’s event mechanism to implement real-time notification; external systems can subscribe to specific types of audit events.

4.11. Correctness Analysis

Theorem 3 (Correctness).

BL-ABSE satisfies the correctness requirement of Definition 13. That is, for any keyword w, policy P, attribute set S satisfying $P\subseteq S$, and plaintext M, if the user has not been revoked, decryption correctly recovers the plaintext with overwhelming probability.

Proof. 

Correctness depends on the simultaneous satisfaction of the following three sub-conditions:

(1) Commitment Matching Correctness. This construction uses the public hash function $H_{\mathrm{seed}}$ to derive seed ${\mathsf{seed}}_c=H_{\mathrm{seed}}\left(w\right)$ from keyword w. Since $H_{\mathrm{seed}}$ is a deterministic function included in the public parameters, the same keyword w, whether at the encryption side or the search side, always produces the same seed ${\mathsf{seed}}_c$, and subsequently derives the same secret polynomial s via GaussianSample. Therefore, the commitment $\mathsf{commit}=a·s+H\left(w\right)$ at the encryption side strictly equals the commitment ${\mathsf{commit}}_q=a·s+H\left(w\right)$ at the search side, with $\mathsf{diff}=0$ and $\mathsf{dist}=0\le B$. For different keywords $w\ne w^{\prime }$, by the randomness of hash function H, each coefficient of $H\left(w\right)-H\left(w^{\prime }\right)$ is approximately uniformly distributed over ${\mathbb{Z}}_q$, and the norm of the difference exceeds B with overwhelming probability.

(2) ABE Decryption Correctness. By the correctness guarantee of the lattice-based CP-ABE construction, when the user attribute set S satisfies the access policy P (i.e., $P\subseteq S$), $\mathsf{ABE.Decrypt}({\mathsf{pp}}_{\mathrm{abe}},{\mathsf{sk}}_{\mathrm{abe},S},C_{\mathrm{abe}})$ correctly recovers data key $K_{\mathrm{data}}$.

(3) Threshold Aggregation Correctness. By the reconstruction property of Shamir secret sharing and the correctness of Lagrange interpolation, when the number of participating nodes $\left|T\right|\ge t$, the aggregated ${\mathsf{sk}}_{\mathrm{abe},S}$ is equivalent to the private key generated directly from the complete master key ${\mathsf{msk}}_{\mathrm{abe}}$.

Determination of Threshold B. Threshold B must satisfy two conditions: (i) for matching keyword pairs, $\mathsf{dist}\le B$ holds with overwhelming probability; (ii) for non-matching keyword pairs, $\mathsf{dist}>B$ holds with overwhelming probability. Since $\mathsf{dist}=0$ when matching (both sides derive identical commitments from the same keyword), condition (i) is satisfied trivially for any $B>0$. For condition (ii), when $w\ne w^{\prime }$, the difference $\mathsf{diff}=H\left(w\right)-H\left(w^{\prime }\right)$ has coefficients that are approximately uniformly distributed over ${\mathbb{Z}}_q$ (by the randomness of H modeled as a random oracle), so the expected squared Euclidean distance after centered reduction is $\mathbb{E}\left[\mathsf{dist}\right]\approx n·q^2/12\approx 1.29\times {10}^{10}$. Setting $B=40$, the ratio $\mathbb{E}\left[\mathsf{dist}\right]/B\approx 3.2\times {10}^8$ provides a safety margin of over eight orders of magnitude. Experimental verification (Section 6.6) confirms this analysis: across 10,000 non-matching keyword pairs, the minimum observed distance is $1.14\times {10}^{10}$, yielding a safety margin of $min\left({\mathsf{dist}}_{\mathrm{non-match}}\right)/B\approx 2.85\times {10}^8$, with zero false positives observed even when B is increased to ${10}^9$. The choice of $B=40$ is therefore extremely conservative and robust across parameter variations ($\sigma \in \{2.0,3.2,4.0,6.0\}$).

In summary, BL-ABSE satisfies correctness. □

4.12. Complexity Analysis

This section analyzes the computational and communication complexity of each BL-ABSE algorithm and compares them with traditional constructions.

Table 3. Complexity analysis of each algorithm.

Algorithm	Computational Complexity	Communication Complexity	On-Chain Interactions	Execution Frequency
$\mathsf{BC}\text{-}\mathsf{Setup}$	$O\left(n^{2}t\right)$	$O\left(n^2\right)$	3 deployments	One-time
$\mathsf{ThresholdKeyGen}$	$O(tnlogn)$	$O\left(tn\right)$	$t+1$ times	Low-frequency
$\mathsf{BC}\text{-}\mathsf{Encrypt}$	$O(nlogn)$	$O\left(n\right)$	1 time	Medium-frequency
$\mathsf{Trapdoor}$	$O(nlogn)$	—	0 times	High-frequency
$\mathsf{BC}\text{-}\mathsf{Search}$	$O\left(\right|\mathsf{DB}|·n)$	$O\left(\right|R|·n)$	$0\sim 1$ times *	High-frequency
$\mathsf{Decrypt}$	$O\left(\right|R|·nlogn)$	$O\left(\right|R|·n)$	0 times	High-frequency
$\mathsf{RevokeAccess}$	$O\left(1\right)$	$O\left(1\right)$	1 time	Low-frequency
$\mathsf{UpdatePolicy}$	$O\left(1\right)$	$O\left(1\right)$	1 time	Low-frequency

* Note: On-chain interactions in $\mathsf{BC}\text{-}\mathsf{Search}$ are 0 (local memory queries) when caching is enabled; only 1 on-chain query is needed on a cache miss.

summarizes the complexity of each algorithm.

Key Analysis. (1) High-frequency operation efficiency: Search token generation ($\mathsf{Trapdoor}$) is executed entirely locally, with no on-chain interactions, at computational complexity $O(nlogn)$. The main overhead of search matching ($\mathsf{BC}\text{-}\mathsf{Search}$) is the commitment matching traversal of the database, requiring $O\left(n\right)$ comparisons per record. With caching enabled, on-chain permission checks degrade to local memory access. (2) Low-frequency operation overhead: Key generation ($\mathsf{ThresholdKeyGen}$) involves t on-chain interactions at computational complexity $O(tnlogn)$; policy registration (the on-chain portion of $\mathsf{BC}\text{-}\mathsf{Encrypt}$) requires 1 on-chain transaction. These operations are infrequent, and the additional overhead is acceptable. (3) Permission management overhead: Revocation and policy updates only involve on-chain state modifications, with $O\left(1\right)$ computational and communication complexity, requiring no re-encryption operations.

Compared with traditional lattice-based ABSE constructions without the blockchain, the high-frequency operations (search and decryption) in BL-ABSE maintain the same asymptotic complexity, and the additional overhead introduced by the blockchain is concentrated in low-frequency management operations. This validates the core design principle of the framework—keeping high-frequency operations lightweight.

5. Security Analysis

This chapter provides rigorous formal proofs of the security properties of the BL-ABSE framework. First, we clearly delineate the scope of the formal proofs and the composition of security guarantees across system components.

5.1. Proof Scope and Composition

The BL-ABSE system comprises both cryptographic primitives and system-level infrastructure.

Table 4. Security proof scope and composition.

Component	Security Property	Guarantee Source	Formally Proved
RLWE commitment	Index indistinguishability	Theorem 3 (→ RLWE)	✓
Search token	Query privacy	Theorem 4 (→ RLWE)	✓
Threshold key mgmt.	Key unrecoverability	Theorem 5 (→ SSS + RLWE)	✓
PBFT consensus	Byzantine fault tolerance	Theorem 6 (→ PBFT)	✓
Audit log	Tamper-evidence	Theorem 8 (→ blockchain)	✓
Revocation	Immediacy	Theorem 9 (→ PBFT liveness)	✓
AES-256-GCM	Data confidentiality + integrity	IND-CCA2 standard assumption	✗
IPFS	Data integrity	Content-addressed hashing	✗
Digital signature	Token unforgeability	EUF-CMA standard assumption	✗
Fabric SDK/TLS	Communication security	TLS standard assumption	✗
Attribute Authority	Attribute correctness	Trust assumption (Assumption 5)	✗

clarifies which components are covered by formal security proofs and which rely on standard security assumptions of their respective primitives.

Components marked ✓ are covered by the formal proofs in this section; their security is rigorously reduced to the hardness of RLWE, SIS, or the guarantees of the PBFT consensus protocol. Components marked ✗ are treated as secure primitives under their standard cryptographic or system-level assumptions. The composition of these components follows the modular design principle: the cryptographic layer (RLWE commitments, ABE, threshold key sharing) operates independently of the blockchain enhancement layer (PBFT, smart contracts, audit logs), and the security of each layer does not depend on the internals of the other. Specifically, the IND-INDEX and IND-TRAPDOOR proofs hold regardless of the blockchain implementation, and the PBFT fault-tolerance guarantees hold regardless of the cryptographic construction.

We now proceed to prove each formal security property.

5.2. Index Indistinguishability

Index indistinguishability is a core security property of searchable encryption protocols, requiring that an adversary cannot distinguish between two different keywords from an encrypted index. The index indistinguishability of BL-ABSE reduces to the hardness of the RLWE decision problem.

Theorem 3 (IND-INDEX Security). BL-ABSE satisfies the $\mathcal{L}$-IND-INDEX security defined in Definition 14. That is, for any PPT (or QPT) adversary $\mathcal{A}$, its advantage in the index indistinguishability game is negligible. Specifically, there exists a PPT (or QPT) algorithm $\mathcal{B}$ such that:

$${\mathsf{Adv}}^{\mathrm{IND-INDEX}}\left(\mathcal{A}\right)\le {\mathsf{Adv}}^{\mathrm{RLWE}}\left(\mathcal{B}\right)+\mathsf{negl}\left(\lambda \right).$$

(14)

Proof Sketch.

We employ the hybrid game reduction technique, constructing a series of hybrid games that gradually reduce the IND-INDEX game to the RLWE decision problem. The key observation is that in the keyword commitment $\mathsf{commit}=a·s+H\left(w\right)$, since s is deterministically derived by the public hash function $H_{\mathrm{seed}}\left(w\right)$, the output of $H_{\mathrm{seed}}$ is computationally indistinguishable from a uniformly random string. Therefore, even though s is generated deterministically, $a·s$ remains indistinguishable from a uniformly random polynomial under the RLWE assumption, so the commitment does not leak information about $H\left(w\right)$.

Proof. 

We define the following sequence of hybrid games:

Game 0 (Real Game): This is the standard IND-INDEX game from Definition 14. The challenger executes $\mathsf{BC}\text{-}\mathsf{Setup}$ to generate public parameters $\mathsf{pp}$, and the adversary $\mathcal{A}$ may adaptively issue encryption queries and search token queries. Finally, $\mathcal{A}$ submits a challenge keyword pair $(w_0^{*},w_1^{*})$ and an access policy $P^{*}$, the challenger selects $b\leftarrow \{0,1\}$ at random and returns the encrypted index $I^{*}$ for $w_b^{*}$. The adversary outputs a guess $b^{\prime }$. Define the adversary’s advantage in Game 0 as:

$${\mathsf{Adv}}_0\left(\mathcal{A}\right)=|Pr[b^{\prime }=b]-1/2|.$$

(15)

Game 1 (Hash Function Replacement): Replace the hash function $H_{\mathrm{seed}}:{\{0,1\}}^{*}\to {\{0,1\}}^{256}$ with a truly random function $\mathsf{RF}$. That is, for each new keyword w, $\mathsf{RF}\left(w\right)$ returns a fresh uniformly random 256-bit string. Since $H_{\mathrm{seed}}$ is modeled as a random oracle (RO) in BL-ABSE, this replacement is equivalent in the random oracle model. In the standard model, if $H_{\mathrm{seed}}$ is instantiated as a cryptographic hash function (e.g., SHA-256), then $|{\mathsf{Adv}}_0\left(\mathcal{A}\right)-{\mathsf{Adv}}_1\left(\mathcal{A}\right)|$ is bounded by the pseudorandomness of $H_{\mathrm{seed}}$ and is negligible.

Game 2 (Gaussian Sampling Replacement): Replace the deterministic Gaussian sampling derived from ${\mathsf{seed}}_c=\mathsf{RF}\left(w\right)$ with a genuinely random Gaussian sample $s\leftarrow {\chi }^n$. Specifically, instead of using a pseudorandom number generator to derive the coefficients of s from ${\mathsf{seed}}_c$, each coefficient is independently sampled from the discrete Gaussian distribution ${\mathcal{D}}_{\mathbb{Z},\sigma }$. Since ${\mathsf{seed}}_c$ is a uniformly random 256-bit string in Game 1, the sampling sequence expanded from ${\mathsf{seed}}_c$ by a cryptographically secure pseudorandom generator (PRG) is computationally indistinguishable from a truly random sequence. Therefore,

$$|{\mathsf{Adv}}_1\left(\mathcal{A}\right)-{\mathsf{Adv}}_2\left(\mathcal{A}\right)|\le {\mathsf{Adv}}^{\mathrm{PRG}}\left({\mathcal{B}}^{\prime }\right)\le \mathsf{negl}\left(\lambda \right),$$

(16)

where ${\mathcal{B}}^{\prime }$ is the reduction algorithm attacking the PRG and ${\mathsf{Adv}}^{\mathrm{PRG}}$ denotes the PRG security advantage.

Game 3 (RLWE Sample Replacement): Replace the commitment in the challenge index from ${\mathsf{commit}}^{*}=a·s^{*}+H\left(w_b^{*}\right)$ to ${\mathsf{commit}}^{*}=u+H\left(w_b^{*}\right)$, where $u\leftarrow R_q$ is a uniformly random polynomial. This replacement directly corresponds to the RLWE decision problem: under the RLWE assumption, $(a,a·s^{*})$ and $(a,u)$ are computationally indistinguishable, where $a\leftarrow R_q$ and $s^{*}\leftarrow {\chi }^n$. Therefore,

$$|{\mathsf{Adv}}_2\left(\mathcal{A}\right)-{\mathsf{Adv}}_3\left(\mathcal{A}\right)|\le {\mathsf{Adv}}^{\mathrm{RLWE}}\left(\mathcal{B}\right)\le \mathsf{negl}\left(\lambda \right),$$

(17)

where $\mathcal{B}$ is the reduction algorithm attacking the RLWE decision problem.

Game 4 (Information-Theoretic Indistinguishability): In Game 3, the challenge commitment is ${\mathsf{commit}}^{*}=u+H\left(w_b^{*}\right)$, where u is uniformly random. Note that the distribution of ${\mathsf{commit}}^{*}$ is completely independent of the choice of b: regardless of whether $b=0$ or $b=1$, ${\mathsf{commit}}^{*}$ follows a distribution of the form $u+H\left(w\right)$, where u is uniformly random. Since addition in $R_q$ forms a group, $u+H\left(w_0^{*}\right)$ and $u+H\left(w_1^{*}\right)$ have the same uniform distribution (even if $H\left(w_0^{*}\right)\ne H\left(w_1^{*}\right)$). This means the challenge commitment leaks no information about b in the information-theoretic sense, and the adversary’s advantage is strictly 0:

$${\mathsf{Adv}}_3\left(\mathcal{A}\right)=0.$$

(18)

Combining the above hybrid games via the triangle inequality:

$${\mathsf{Adv}}^{\mathrm{IND-INDEX}}\left(\mathcal{A}\right)={\mathsf{Adv}}_0\left(\mathcal{A}\right)\le {\mathsf{Adv}}^{\mathrm{PRG}}\left({\mathcal{B}}^{\prime }\right)+{\mathsf{Adv}}^{\mathrm{RLWE}}\left(\mathcal{B}\right)\le \mathsf{negl}\left(\lambda \right).$$

(19)

This completes the proof of Theorem 3. □

Discussion. The key insight of this proof is demonstrating the security of the deterministic commitment mechanism. Although the secret polynomial s is deterministically derived from the keyword w via the public hash function $H_{\mathrm{seed}}$ (rather than from a user’s private key), the commitment $a·s+H\left(w\right)$ still does not leak information about $H\left(w\right)$. This is because: (1) the output of $H_{\mathrm{seed}}$ is computationally pseudorandom; (2) Gaussian samples derived from a pseudorandom seed are computationally indistinguishable from truly random Gaussian samples; and (3) under the RLWE assumption, $a·s$ is indistinguishable from a uniformly random polynomial. Therefore, even though the adversary knows that $H_{\mathrm{seed}}$ is a public parameter, it cannot extract keyword information from the commitment.

5.3. Query Privacy

Query privacy guarantees that search tokens do not reveal information about the query keyword. The search token $T_w=({\mathsf{commit}}_q,S,ts,\mathsf{expiry},{\sigma }_{\mathrm{user}})$ in BL-ABSE consists of a keyword commitment, a user attribute set, a timestamp, and a signature. We prove that an adversary cannot distinguish search tokens for different query keywords from ${\mathsf{commit}}_q$.

Theorem 4 (IND-TRAPDOOR Security).

BL-ABSE satisfies the $\mathcal{L}$-IND-TRAPDOOR security defined in Definition 15. That is, for any PPT (or QPT) adversary $\mathcal{A}$, its advantage in distinguishing the search tokens of two different keywords is negligible.

Proof. 

The proof of query privacy follows a structure analogous to that of index indistinguishability. The query commitment ${\mathsf{commit}}_q=a·s+H\left(w\right)$ in the search token has the same structure as the commitment in the encrypted index. By the proof of Theorem 3, ${\mathsf{commit}}_q$ is computationally indistinguishable from a uniformly random polynomial, and therefore does not leak information about the keyword w.

Formally, suppose there exists an adversary $\mathcal{A}$ that can distinguish the search tokens for keywords $w_0$ and $w_1$ with non-negligible advantage. We construct a reduction algorithm $\mathcal{B}$ to attack the RLWE decision problem: $\mathcal{B}$ receives an RLWE challenge $(a,b)$ (where $b=a·s+e$ or $b\leftarrow R_q$), generates public parameters $\mathsf{pp}$ (including a), and returns $b+H\left(w_b\right)$ (where $b\leftarrow \{0,1\}$) to $\mathcal{A}$ as the query commitment. If $\mathcal{A}$ can distinguish the tokens for the two keywords, then $\mathcal{B}$ can distinguish RLWE samples, contradicting the RLWE assumption.

Furthermore, the attribute set S, timestamp $ts$, and signature ${\sigma }_{\mathrm{user}}$ in the search token are public or publicly verifiable information and do not involve keyword content. The role of the timestamp and signature is to prevent token replay and forgery, not to conceal keywords. Therefore, the query privacy of the search token is entirely guaranteed by the indistinguishability of the commitment. □

5.4. Threshold Key Security

BL-ABSE employs $(t,n)$ threshold secret sharing for decentralized key management. The master key $\mathsf{msk}$ is split into n shares, each held by an edge node; any t nodes can collaboratively recover the complete key, while any fewer than t nodes obtain no information about $\mathsf{msk}$ whatsoever. This section proves the security of threshold key management.

Theorem 5 (Threshold Key Security).

Under the $(t,n)$ threshold configuration of BL-ABSE, for any PPT adversary $\mathcal{A}$ that compromises at most $t-1$ edge nodes, its advantage in recovering the complete master key $\mathsf{msk}$ is negligible.

Proof. 

BL-ABSE employs Shamir’s secret sharing protocol, whose information-theoretic security guarantees that any $t-1$ or fewer shares reveal no information about the secret $\mathsf{msk}$ in the information-theoretic sense.

Specifically, during the system initialization phase (Algorithm 1), each node ${\mathsf{EN}}_i$ generates a random degree-$(t-1)$ polynomial $f_i\left(x\right)={\mathsf{msk}}_i+a_{i,1}·x+\dots +a_{i,t-1}·x^{t-1}modq$, where ${\mathsf{msk}}_i$ is the secret contribution of that node and $a_{i,1},\dots ,a_{i,t-1}\leftarrow {\mathbb{Z}}_q$ are random coefficients. Node ${\mathsf{EN}}_i$ computes the share $s_{i,j}=f_i\left(j\right)$ and sends it secretly to node ${\mathsf{EN}}_j$. Finally, node ${\mathsf{EN}}_j$ holds the complete share:

$${\mathsf{sk}}_j={\displaystyle \sum _{i=1}^n}{s}_{i,j}={\displaystyle \sum _{i=1}^n}{f}_i\left(j\right)=f\left(j\right),$$

(20)

where $f\left(x\right)={\sum }_i{f}_i\left(x\right)$ is the sum of all nodes’ polynomials, still a degree-$(t-1)$ polynomial, whose constant term $f\left(0\right)={\sum }_i{\mathsf{msk}}_i=\mathsf{msk}$ is the master key.

By the information-theoretic security of Shamir’s secret sharing, any $k<t$ shares ${\left\{{\mathsf{sk}}_j\right\}}_{j\in T}$, $\left|T\right|=k$, correspond to k point-value constraints on $f\left(x\right)$. Since $f\left(x\right)$ is a degree-$(t-1)$ polynomial with t degrees of freedom (t coefficients), $k<t$ constraints cannot uniquely determine $f\left(x\right)$. More precisely, for any candidate master key ${\mathsf{msk}}^{\prime }$, there exists at least one degree-$(t-1)$ polynomial $f^{\prime }\left(x\right)$ consistent with the known k shares such that $f^{\prime }\left(0\right)={\mathsf{msk}}^{\prime }$. This means that from the perspective of k shares, all possible master key values are equally probable, and the adversary gains zero information about $\mathsf{msk}$.

Therefore, an adversary that compromises at most $t-1$ nodes cannot obtain any information about the master key $\mathsf{msk}$, let alone recover it. Theorem 5 is proved. □

Corollary 1.

In a typical $(3,5)$ configuration, an adversary that compromises 2 nodes cannot recover the master key. In a $(4,7)$ configuration, an adversary that compromises 3 nodes cannot recover the master key.

Lemma 1 (PBFT–Threshold Parameter Constraint).

For BL-ABSE to simultaneously satisfy both PBFT consensus security and threshold key security, the threshold parameter t must satisfy $t>f_{\mathrm{PBFT}}+1$, where $f_{\mathrm{PBFT}}=\lfloor (n-1)/3\rfloor$ is the maximum number of Byzantine nodes tolerated by PBFT.

Proof. 

The PBFT consensus mechanism tolerates at most $f_{\mathrm{PBFT}}$ malicious nodes while guaranteeing safety and liveness. Meanwhile, the $(t,n)$ Shamir secret sharing scheme ensures information-theoretic security as long as the adversary controls fewer than t nodes. For both guarantees to hold simultaneously, we require: (1) the adversary cannot reach the threshold t even when controlling the maximum number of PBFT-tolerable malicious nodes, i.e., $f_{\mathrm{PBFT}}<t$; (2) there must exist enough honest nodes to both reach PBFT consensus and participate in key generation, i.e., $n-f_{\mathrm{PBFT}}\ge t$.

If $t\le f_{\mathrm{PBFT}}$, an adversary controlling exactly $f_{\mathrm{PBFT}}$ nodes (which PBFT considers tolerable) would hold t or more shares, enabling full master key reconstruction—a catastrophic breach. Setting $t>f_{\mathrm{PBFT}}+1$ ensures a safety margin of at least 2 between the PBFT tolerance bound and the reconstruction threshold. Furthermore, since $n-f_{\mathrm{PBFT}}\ge 2f_{\mathrm{PBFT}}+1>t$ for typical configurations, enough honest nodes exist to complete key generation. Table 5 shows recommended parameter configurations. □

Table 5. Recommended PBFT–threshold parameter configurations.

n (Nodes)	${\mathit{f}}_{\mathbf{PBFT}}$	Recommended t	Safety Margin t $-{\mathit{f}}_{\mathbf{PBFT}}$	Notes
4	1	3	2	Minimum practical config.
5	1	3	2	Default config. in this paper
7	2	4	2	Standard deployment
10	3	5	2	Large-scale deployment
13	4	7	3	High-security deployment

Table 5. Recommended PBFT–threshold parameter configurations.

n (Nodes)	${\mathit{f}}_{\mathbf{PBFT}}$	Recommended t	Safety Margin t $-{\mathit{f}}_{\mathbf{PBFT}}$	Notes
4	1	3	2	Minimum practical config.
5	1	3	2	Default config. in this paper
7	2	4	2	Standard deployment
10	3	5	2	Large-scale deployment
13	4	7	3	High-security deployment

5.5. Byzantine Fault Tolerance

BL-ABSE is built on the PBFT consensus mechanism of Hyperledger Fabric, ensuring system security and liveness even when some edge nodes are malicious or faulty. This section analyzes the Byzantine fault tolerance properties of the framework.

Theorem 6 (Byzantine Fault Tolerance Security).

BL-ABSE satisfies the Byzantine fault tolerance property defined in Definition 17. When the total number of edge nodes $n\ge 3f+1$, the system can tolerate at most $f=\lfloor (n-1)/3\rfloor$ Byzantine nodes while guaranteeing: (1) Safety: honest nodes will not accept invalid key shares or blockchain transactions; (2) Liveness: legitimate users’ key requests and search requests will eventually be processed.

Proof. 

The correctness of the PBFT consensus protocol has been proved in classical literature. We explain how BL-ABSE leverages PBFT to achieve Byzantine fault tolerance, and provide specific safety and liveness arguments.

(1) Safety requires that honest nodes will not accept invalid data submitted by malicious nodes. BL-ABSE guarantees safety through the following mechanisms:

Zero-Knowledge Proof Verification: During threshold key generation (Algorithm 2), each node must submit a zero-knowledge proof ${\pi }_i$ together with its partial key ${\mathsf{sk}}^{\left(i\right)}$, proving that ${\mathsf{sk}}^{\left(i\right)}$ was correctly computed from that node’s share ${\mathsf{sk}}_i$. The KeyManagement smart contract verifies all proofs before executing key aggregation. Even if f malicious nodes submit incorrect partial keys, as long as at least $2f+1$ honest nodes execute correctly and the contract requires at least t valid proofs ($t\ge 2f+1$), the aggregation result remains correct.

PBFT Consensus Verification: All transactions on the blockchain (policy registration, permission revocation, audit logs, etc.) are confirmed through PBFT consensus. PBFT guarantees that under $n\ge 3f+1$, even with f malicious nodes, all honest nodes reach agreement on the validity and execution order of transactions. Specifically, the three-phase protocol of PBFT (Pre-Prepare, Prepare, Commit) ensures that a transaction is confirmed if and only if at least $2f+1$ nodes approve it, and with at most f malicious nodes, at least $f+1$ honest nodes participate in confirmation, guaranteeing transaction validity.

(2) Liveness requires that legitimate users’ requests will eventually be processed. The liveness of BL-ABSE depends on the following conditions:

Sufficient Honest Nodes: As long as the number of honest nodes $h\ge 2f+1$, the system can reach consensus. In threshold key generation, the parameter t is typically set to $\lceil (n+1)/2\rceil$ or larger, ensuring that a majority of nodes must participate. Under the condition $n\ge 3f+1$, the number of honest nodes $h\ge 2f+1>t$, so there are always enough honest nodes to complete key generation.

Timeout and Retry Mechanism: If some nodes refuse to participate or have delayed responses, the protocol design of BL-ABSE includes a timeout mechanism. In key generation, if the waiting time exceeds a preset threshold, the system may select other honest nodes to re-initiate the protocol. Since the number of honest nodes is sufficient, t responding honest nodes can always eventually be found.

Liveness Guarantee of PBFT: The PBFT protocol guarantees liveness under the network synchrony assumption—even in the presence of f malicious nodes and network delays, once the network eventually recovers synchrony, legitimate transactions will be confirmed. The Hyperledger Fabric implementation further handles primary node failures through the View Change mechanism, ensuring continuous system operation.

Combining the above analysis, BL-ABSE satisfies both safety and liveness under the configuration $n\ge 3f+1$. Theorem 6 is proved. □

5.6. Post-Quantum Security

The core cryptographic constructions of BL-ABSE are based on the RLWE and SIS problems, neither of which currently has a known polynomial-time quantum algorithm. Consequently, the framework achieves post-quantum security. This section discusses security in the quantum adversary model.

Theorem 7 (Post-Quantum Security).

In Theorems 3–5, if PPT adversaries are replaced by QPT (quantum polynomial-time) adversaries, the security conclusions of BL-ABSE still hold. That is, BL-ABSE satisfies post-quantum IND-INDEX security, post-quantum IND-TRAPDOOR security, and post-quantum threshold key security.

Proof Sketch. 

The proof of post-quantum security relies on the resistance of lattice problems against quantum algorithms. We analyze each aspect:

(1) Quantum Hardness of the RLWE Problem: The hardness of the RLWE decision problem under the quantum computing model has been extensively studied. In his seminal 2005 work, Regev proved that the standard LWE problem admits worst-case reductions from the GapSVP and SIVP problems on lattices. Lyubashevsky et al. extended this result to RLWE, proving that the hardness of RLWE in the quantum computing model can be reduced to approximation variants of the shortest vector problem on ideal lattices.

The best currently known quantum algorithms for approximating SVP on an n-dimensional lattice still require $2^{\Omega \left(n\right)}$ time. Even accounting for the quadratic speedup provided by Grover’s algorithm (reducing classical brute-force search from $O\left(2^n\right)$ to $O\left(2^{n/2}\right)$), for the parameter $n=1024$ used in BL-ABSE, the complexity of quantum attacks remains $2^{512}$, far beyond feasible computation. Therefore, the RLWE problem remains hard in the quantum computing model.

(2) Quantum Hardness of the SIS Problem: The binding property of the BL-ABSE commitment construction reduces to the Short Integer Solution (SIS) problem. SIS requires finding a short vector $\mathbf{x}$ such that $\mathbf{A}\mathbf{x}=0modq$, where $\mathbf{A}$ is a random matrix. The SIS problem can be reduced to SVP on lattices, thus inheriting the quantum hardness of SVP. The survey by Micciancio and Regev indicates that the optimal quantum algorithms for the SIS problem still require exponential time.

(3) Information-Theoretic Security of Threshold Secret Sharing: The security of Shamir’s secret sharing protocol is information-theoretic and does not rely on any computational assumption. Even if the adversary has unlimited quantum computing power, any $t-1$ or fewer shares still reveal no information about the secret in the information-theoretic sense. Therefore, the security of threshold key management is fully preserved in the quantum model.

(4) Quantum Security of Symmetric Cryptography: BL-ABSE uses AES-256-GCM for data encryption. Although Grover’s algorithm can reduce the security of AES-256 from 256 bits to 128 bits (through quadratic-speedup exhaustive search), a 128-bit security level is still considered sufficient in practice. For higher assurance, one may upgrade to AES-512 (if standardized) or adopt other quantum-resistant symmetric ciphers such as ChaCha20.

Combining the above analysis, the core security properties of BL-ABSE continue to hold in the quantum computing model. Theorem 7 is proved. □

NIST Post-Quantum Cryptography Standardization Validation. The lattice-based cryptography adopted by BL-ABSE has been selected in the NIST Post-Quantum Cryptography Standardization process. In 2022, NIST announced the first batch of post-quantum cryptographic standards, in which CRYSTALS-Kyber (based on Module-LWE) was selected as the key encapsulation mechanism standard and CRYSTALS-Dilithium (based on Module-SIS) was selected as the digital signature standard. These constructions share the same RLWE/SIS assumptions as BL-ABSE, further validating the quantum-resistance of lattice-based cryptography.

5.7. Audit Tamper-Evidence

BL-ABSE stores audit logs on the blockchain, leveraging the immutability of the blockchain to ensure traceability and integrity of the operation history. This section analyzes the security properties of audit logs.

Theorem 8 (Audit Tamper-Evidence).

BL-ABSE satisfies the audit tamper-evidence property defined in Definition 18. That is, for any PPT adversary $\mathcal{A}$, the probability of modifying historical audit logs without being detected is negligible.

Proof. 

The immutability of the blockchain stems from the combination of its cryptographic hash-chain structure and consensus mechanism. We analyze how BL-ABSE leverages these properties to guarantee the integrity of audit logs.

(1) Cryptographic Hash Chain: Each block in the blockchain contains the cryptographic hash (e.g., SHA-256) of the preceding block. To modify an audit log in block i, an adversary must: (i) modify the content of that block; (ii) recompute the hash of that block; (iii) modify the predecessor hash stored in block $i+1$; (iv) recursively modify all subsequent blocks.

Since SHA-256 satisfies collision resistance (the probability of finding two distinct inputs that produce the same hash is negligible), the adversary cannot modify block content without changing the hash value. Therefore, any modification to a historical block will break the hash chain and be detected by honest nodes.

(2) Distributed Consensus Verification: Even if an adversary can modify the blockchain replica on its own node, the modified chain is inconsistent with the chains of other honest nodes. Under the PBFT consensus mechanism, confirming a block requires the approval of at least $2f+1$ nodes. For the adversary to have its modified block accepted by the system, it would need to control at least $2f+1$ nodes, which requires $f\ge (n+1)/3$, violating the assumption $n\ge 3f+1$.

Furthermore, even if the adversary controls $f<(n+1)/3$ nodes and attempts to fork the chain (creating a parallel chain with falsified logs), the finality guarantee of PBFT ensures that confirmed blocks will not be rolled back. Honest nodes will refuse to accept any chain inconsistent with the confirmed history.

(3) Multi-Party Witnessing: Audit logs in BL-ABSE are recorded by the AuditLog smart contract, with each recording operation corresponding to a blockchain transaction. Once a transaction is confirmed, its hash and timestamp are permanently written on-chain and witnessed by all n nodes. To tamper with an audit log entry, the adversary would need to simultaneously control more than $2/3$ of the nodes, which is impossible under the honest-majority assumption.

Combining the above analysis, under the collision-resistance assumption of SHA-256 and the security guarantees of PBFT, an adversary cannot modify historical audit logs without being detected. Theorem 8 is proved. □

Practical Detection Mechanisms. BL-ABSE deploys the following mechanisms to enhance the verifiability of audit logs: (1) Blockchain Explorer: provides a graphical interface for querying and verifying audit logs, displaying the transaction hash, block number, and timestamp for each log entry; (2) Merkle Proof: for scenarios that require proving the existence of a log entry to an external auditor, the system can generate a Merkle path from the log entry to the block root hash, providing a concise existence proof; (3) Periodic Snapshots: the system periodically publishes the Merkle root of the blockchain state to publicly trusted platforms (e.g., newspapers, notary services), further enhancing the verifiability of historical records.

5.8. Revocation Immediacy

BL-ABSE achieves immediate permission revocation through an on-chain revocation list. Compared with traditional approaches that require re-encryption of data (which can take hours), on-chain revocation takes effect immediately upon block confirmation (approximately 2 s). This section formalizes this property.

Theorem 9 (Revocation Immediacy).

BL-ABSE satisfies the revocation immediacy property defined in Definition 19. That is, if user u is revoked access to data d at time t, then for any search request issued at time $t^{\prime }>t+{\Delta }_{\mathrm{confirm}}$ (where ${\Delta }_{\mathrm{confirm}}\approx 2$ s is the blockchain confirmation delay), user u cannot retrieve data d.

Proof. 

The proof of revocation immediacy is divided into two parts: the time bound for revocation taking effect and the enforcement of revocation.

(1) Revocation Effective Time: At time t, the data owner invokes the $\mathsf{RevokeAccess}(\mathsf{dataId},\mathsf{userId})$ algorithm (Algorithm 7), which submits a revocation transaction to the blockchain. Under PBFT consensus, transaction confirmation requires: (i) broadcasting the transaction to all nodes (network delay $<100$ ms); (ii) the three-phase consensus protocol (Pre-Prepare, Prepare, Commit), with each phase requiring message exchanges between nodes; (iii) writing the transaction into a new block.

In a typical Hyperledger Fabric configuration, the block generation time is set to 2 s (Algorithm 1, Line 6). Therefore, the time from submitting the revocation transaction to confirming it on the blockchain is ${\Delta }_{\mathrm{confirm}}\approx 2$ s (plus network delay, in practice 2–3 s). Once the transaction is confirmed, the revocation record becomes immediately visible to all honest nodes.

(2) Enforcement of Revocation: The search algorithm $\mathsf{BC}\text{-}\mathsf{Search}$ (Algorithm 5) performs an on-chain revocation check (Line 7) before returning results:

$$\mathrm{if}\mathsf{AccessControl.isRevoked}(\mathsf{dataId},\mathsf{userId})\mathrm{then}\mathrm{continue}.$$

(21)

This check queries the latest state on the blockchain. For a search request issued at time $t^{\prime }>t+{\Delta }_{\mathrm{confirm}}$, the revocation transaction has already been confirmed, $\mathsf{AccessControl.isRevoked}(d,u)$ returns true, and the search algorithm skips the data item without adding it to the result set.

It is worth noting that the revoked user u still holds a valid user private key ${\mathsf{sk}}_u$ and search token $T_w$ at time $t^{\prime }$. However, since the revocation check in the search algorithm is mandatory (Algorithm 5, Line 7, executed unconditionally), even if the user attempts to directly access the cloud storage to obtain the ciphertext CID, they still cannot bypass revocation—data access is protected by ABE ciphertext, and the ABE ciphertext policy may have been updated after revocation (via $\mathsf{UpdatePolicy}$); or even if the policy remains unchanged, the audit log will record the unauthorized access attempt and trigger a security alert.

Combining the above analysis, BL-ABSE guarantees that all search requests from a revoked user will be rejected within approximately 2 s after the revocation transaction is confirmed. Theorem 9 is proved. □

Comparison with Traditional Approaches. Traditional attribute-based searchable encryption constructions achieve revocation through key updates or data re-encryption. Key update approaches require regenerating private keys for all non-revoked users and securely distributing them, which may take minutes; data re-encryption methods require re-encrypting all affected data and updating indexes, which may take hours or even days for large-scale datasets. In contrast, BL-ABSE’s on-chain revocation list mechanism reduces revocation latency to the second level, without requiring any re-encryption or key redistribution, substantially improving the efficiency of dynamic permission management.

5.9. Search Pattern Leakage Analysis

The deterministic commitment mechanism of BL-ABSE—wherein the same keyword w always produces the same commitment $\mathsf{commit}=a·s+H\left(w\right)$—is essential for non-interactive search matching but inherently leaks the search pattern: an adversary observing encrypted indices and search tokens can determine whether two queries target the same keyword. This section quantitatively analyzes three concrete attack vectors and characterizes the resulting privacy implications.

5.9.1. Theoretical Frequency Analysis

An adversary who observes a stream of search tokens can count the frequency of each distinct commitment and attempt to match these frequencies against a known keyword distribution (e.g., Zipf’s law). Our experimental analysis (Section 6.8) evaluates this attack across varying vocabulary sizes ($\left|\mathcal{W}\right|\in \{100,500,1000\}$) and distribution skewness parameters ($\alpha \in \{1.0,1.5,2.0\}$). The results show that keyword recovery rates remain modest in realistic settings: for $\left|\mathcal{W}\right|=1000$ and $\alpha =1.0$ (near-uniform distribution), the recovery rate is only 2.5% even after observing 10,000 queries. However, for small vocabularies with highly skewed distributions ($\left|\mathcal{W}\right|=100$, $\alpha =2.0$), the rate increases to 14.9%, indicating that frequency analysis is more effective when the keyword space is small and queries are concentrated on a few popular terms.

5.9.2. Dictionary Attack

Since $H_{\mathrm{seed}}$ is a public parameter, an adversary with a candidate keyword dictionary $\mathcal{D}$ can precompute commitments for all $w\in \mathcal{D}$ and compare them against observed commitments. This is a more powerful attack than frequency analysis: when $\mathcal{D}$ covers the actual keyword space, the adversary achieves 100% keyword identification. This is a fundamental consequence of the deterministic design and is shared by all searchable encryption protocols that support non-interactive keyword matching with equality testing. The primary defense is to ensure that the effective keyword space is large and that keywords are drawn from a sufficiently high-entropy distribution.

5.9.3. Cross-User Linkage

Because the commitment derivation uses only the public parameters a, H, and $H_{\mathrm{seed}}$ (and not user-specific keys), different users searching for the same keyword produce identical commitments. An adversary can thus link queries across users with certainty. Experimental results confirm that 100% of user pairs sharing at least one keyword are linkable, with an average of approximately 20 shared keywords per pair (out of 100 queries each from a vocabulary of 500).

5.9.4. Correctness–Privacy Trade-Off

The search-pattern leakage described above is not a flaw in the security proof but rather a fundamental design trade-off: deterministic commitments are necessary for non-interactive, exact-match search correctness (Theorem 3), while randomized commitments would eliminate pattern leakage at the cost of requiring interactive protocols or server-side trial decryption, significantly increasing communication complexity and search latency.

BL-ABSE explicitly operates within the $\mathcal{L}$-IND-INDEX security framework (Definition 14), where the leakage function ${\mathcal{L}}_{\mathsf{Search}}$ includes the search pattern $\mathsf{sp}\left(w\right)=\{i:w_i=w\}$. The formal proofs in Theorems 3 and 4 guarantee that no information beyond this declared leakage is revealed. Known inference attacks (e.g., file-injection attacks [3], query recovery attacks [4]) exploit precisely this leakage; the defense strategies discussed in Section 7.2 (ORAM integration, differential privacy) can compress the exploitable leakage at the cost of additional overhead.

6. Experimental Evaluation

6.1. Experimental Setup

All experiments are conducted on a server equipped with an Intel Xeon E5-2680 v4 processor (Intel Corporation, Santa Clara, CA, USA) (2.4 GHz, 14 cores), 64 GB DDR4 RAM, running Ubuntu 22.04 LTS (Canonical Ltd., London, UK). The prototype system is implemented in Python 3.10 (Python Software Foundation, Wilmington, DE, USA) with NumPy 1.24 for polynomial arithmetic and hashlib/SHAKE-256 for hash functions. Blockchain experiments use Hyperledger Fabric 2.5 (Linux Foundation, San Francisco, CA, USA) with PBFT consensus configured at a 2-s block time, deployed across Docker containers (Docker Inc., Palo Alto, CA, USA). Each experimental group is independently repeated 30 times unless otherwise stated, with mean ± standard deviation reported.

The RLWE parameters are $n=1024$, $q=\mathrm{12,289}$, $\sigma =3.2$, and $B=40$ throughout all experiments, consistent with the parameter choices in Section 4.2. The NTT implementation uses precomputed root-of-unity tables and bit-reversal permutation, as described in Section 2.3.

6.2. NTT Optimization Effectiveness Evaluation

As noted in Section 4.4, the keyword commitment generation of the BL-ABSE framework relies on polynomial ring multiplication in $R_q={\mathbb{Z}}_q\left[x\right]/(x^n+1)$. The naïve implementation has a computational complexity of $O\left(n^2\right)$, which introduces significant computational bottlenecks at the lattice dimension $n=1024$. To this end, the framework introduces Number Theoretic Transform (NTT) optimization based on negacyclic convolution, reducing polynomial multiplication complexity to $O(nlogn)$. This section verifies the practical effectiveness of this optimization through comparative experiments.

Experiments are conducted at four sets of lattice dimensions $n\in \{256,512,1024,2048\}$. The RLWE parameters are fixed at $q=\mathrm{12,289}$ and $\sigma =3.2$, consistent with the parameter choices in Section 4.2 for system initialization. For each parameter set, 50 commitment generation operations are executed separately using naïve polynomial multiplication and NTT-optimized multiplication, with average execution time and standard deviation recorded. The precomputation overhead of NTT (construction of the table of roots of unity and the bit-reversal permutation table) is completed once during system initialization and is not counted in the single commitment generation time, consistent with the actual deployment execution flow. Results are shown in

Table 6. Comparison of keyword commitment generation time before and after NTT optimization.

Lattice Dim. n	Naive Method Avg. (ms)	Naive Method Std. (ms)	NTT Opt. Avg. (ms)	NTT Opt. Std. (ms)
256	23.38	1.53	4.93	0.50
512	103.56	14.10	10.76	0.69
1024	401.43	13.01	23.13	0.68
2048	1615.67	31.98	51.63	1.53

Note: Bold values in the $n=1024$ row indicate the default parameter configuration adopted by BL-ABSE, which achieves 128-bit post-quantum security.

.

From Table 6, the following observations can be made. First, NTT optimization achieves significant performance gains across all tested dimensions. At the core parameter $n=1024$ of this framework, the naïve method has an average commitment generation time of 401.43 ms, which is reduced to 23.13 ms after NTT optimization, yielding a speedup of 17.4×. Second, the speedup increases monotonically with the lattice dimension, growing from 4.7× at $n=256$ to 31.3× at $n=2048$. This trend is consistent with theoretical analysis: the complexity of the naïve method is $O\left(n^2\right)$ and that of the NTT method is $O(nlogn)$, whose ratio asymptotically approaches $O(n/logn)$, increasing as n grows. Finally, the standard deviation of NTT-optimized execution times is significantly smaller than that of the naïve method (e.g., 0.68 ms vs. 13.01 ms at $n=1024$), indicating that NTT execution times are more stable, which has important implications for latency predictability in edge computing scenarios.

These results validate the effectiveness of the NTT optimization design in Section 4.4, showing that BL-ABSE can control the computational latency of keyword commitment generation at the millisecond level while maintaining the 128-bit post-quantum security level ($n=1024$), meeting the performance requirements of real-time encrypted search on edge devices. It should be noted that this experiment is based on a Python prototype implementation; engineering optimizations at the C/C++ level (such as Montgomery reduction discussed in Section 2.3) can further reduce absolute execution time.

Security–Efficiency Trade-off. Table 6 also reveals the security–efficiency trade-off inherent in the lattice dimension parameter n. As n increases from 256 to 2048, the security level grows from approximately 64-bit to 256-bit post-quantum security, while the NTT-optimized commitment generation time increases from 4.93 ms to 51.63 ms—a 10.5× increase in computation for a 4× increase in security. At the chosen parameter $n=1024$ (128-bit security), the commitment generation time of 23.13 ms represents a practical sweet spot for edge-computing scenarios where sub-100 ms latency is required.

6.3. Comparative Analysis with Existing Approaches

To comprehensively evaluate the functional completeness and technical advantages of BL-ABSE, this section systematically compares BL-ABSE with thirteen representative constructions published in recent years, across two dimensions: functional features and computational complexity. The selected works cover three main research directions: attribute-based searchable encryption (ABSE), post-quantum searchable encryption, and blockchain-enhanced searchable encryption.

6.3.1. Comparison of Functional Features

Table 7. Comparison of functional features between BL-ABSE and existing approaches.

Approach	Security Assumption	PQ Secure	Access Control	Decen. Key Mgmt	Blockchain	Instant Revoc.	Audit Log	NTT Opt.
Zhang et al. [10]	DBDH/DL	✗	CP-ABE	✗	✗	✗	✗	✗
Yu et al. [26]	DBDH/DL	✗	MA-ABE	△	✓	✓	✗	✗
Luo et al. [9]	DBDH/DL	✗	CP-ABE	✗	✗	✗	✗	✗
Niu et al. [11]	DBDH/DL	✗	CP-ABE	✗	✗	△	✗	✗
Yin et al. [27]	DBDH/DL	✗	CP-ABE	✓	✓	✗	△	✗
Shen et al. [22]	LWE	✓	MA-ABE	△	✗	✓	✗	✗
Cao et al. [24]	LWE	✓	CP-ABE	✗	✗	✗	✗	✗
Huang et al. [25]	LWE	✓	ABE	✗	✗	✗	✗	✗
Yang et al. [23]	RLWE	✓	CP-ABE	✗	✗	✗	✗	△
Liu et al. [21]	RLWE/SIS	✓	PEKS	✗	✗	✗	✗	✗
Zhang et al. [20]	LWE	✓	PEKS	✗	✗	✗	✗	✗
Wang et al. [28]	q-BDHE/DDH	✗	CP-ABE	✗	✗	✗	✗	✗
Yan et al. [30]	DBDH/DL	✗	ABE	✗	✓	✗ a	✓	✗
BL-ABSE (Ours)	RLWE/SIS	✓	CP-ABE	✓	✓	✓	✓	✓

Note: ✓ = fully supported; △ = partially supported; ✗ = not supported. Bold values in the last row indicate the proposed BL-ABSE approach. ^a Yan et al. [30] use the blockchain but the revocation process still requires proxy re-encryption.

compares the functional features of each approach across nine key dimensions. The results show that BL-ABSE is the only framework that simultaneously satisfies all functional requirements.

On the post-quantum security dimension, constructions based on bilinear pairings [9,10,11,26,27] all rely on discrete logarithm or DBDH assumptions and will be completely broken against quantum computing attacks. Shen et al. [22], Cao et al. [24], Huang et al. [25], Yang et al. [23], Liu et al. [21], and Zhang et al. [20] introduce lattice-based constructions to achieve post-quantum security, but none simultaneously addresses a decentralized trust model and on-chain governance mechanisms.

On the decentralized key management dimension, Yu et al. [26] and Shen et al. [22] achieve partial decentralization through a multi-authority architecture, but the former is based on traditional cryptographic assumptions while the latter does not incorporate blockchain enhancement. Yin et al. [27] achieve threshold key management through the blockchain but lack post-quantum security guarantees. The remaining works [9,11,20,21,23,24,25,28] all rely on a single key generation center, with single-point-of-failure and key escrow risks.

On the permission revocation dimension, approaches differ significantly. In terms of revocation granularity, [22,24,25,28] support only attribute-level revocation, Ref. [30] supports only user-level revocation, [24] supports both granularities but relies on a centralized key generation center, while BL-ABSE implements both attribute-level and user-level revocation simultaneously through smart contracts without requiring a trusted third party.

Regarding audit traceability, only Yin et al. [27] and Yan et al. [30] provide limited audit capabilities using the blockchain, but the audit granularity is limited and does not cover key operations such as search queries and policy changes. BL-ABSE leverages the immutability of the blockchain to record complete operation logs, providing cryptographic-level evidence for post-hoc accountability.

6.3.2. Comparison of Computational Complexity

Table 8. Comparison of computational complexity between BL-ABSE and existing approaches.

Approach	Encryption Complexity	Search Complexity	Token Gen. Complexity	Key Storage
Zhang et al. [10]	$O\left(\right|U\left|\right)P$	$O\left(\right|\mathsf{DB}\left|\right)P$	$O\left(\right|S\left|\right)P$	$O\left(\right|S\left|\right)$
Yu et al. [26]	$O\left(\right|U\left|\right)P$	$O\left(\right|\mathsf{DB}\left|\right)P$	$O\left(\right|S\left|\right)P$	$O\left(\right|S\left|\right)$
Shen et al. [22]	$O\left(n^2\right)$	$O\left(\right|\mathsf{DB}|·n^2)$	$O\left(n^2\right)$	$O\left(n\right)$
Yang et al. [23]	$O(nlogn)$	$O\left(\right|\mathsf{DB}|·n)$	$O(nlogn)$	$O\left(n\right)$
Liu et al. [21]	$O\left(n^2\right)$	$O\left(\right|\mathsf{DB}|·n^2)$	$O\left(n^2\right)$	$O\left(n\right)$
BL-ABSE (Ours)	$\mathit{O}(\mathit{n}log\mathit{n})$	$\mathit{O}\left(\right|\mathsf{DB}|·\mathit{n})$	$\mathit{O}(\mathit{n}log\mathit{n})$	$\mathit{O}\left(\mathit{n}\right)$

Note: P denotes one bilinear pairing operation; n is the lattice dimension ($n=1024$ in this work); $\left|\mathsf{DB}\right|$ is the database size; $\left|U\right|$ is the size of the attribute universe; $\left|S\right|$ is the size of the user attribute set. Bold values in the last row indicate the proposed BL-ABSE approach.

provides a quantitative comparison of representative approaches on the computational complexity dimension. In the encryption and token generation phases, the core overhead of bilinear-pairing-based constructions [10,26] is $O\left(\right|U\left|\right)$ or $O\left(\right|S\left|\right)$ pairing operations, which becomes significant for large attribute sets. Constructions based on naïve lattice operations [21,22], while achieving post-quantum security, have $O\left(n^2\right)$ polynomial multiplication complexity, resulting in high per-encryption latency at $n=1024$ that is difficult to meet in real-time deployment scenarios. Yang et al. [23] partially introduce NTT optimization through an offline/online strategy but do not provide a complete NTT-accelerated implementation and only optimize the encryption phase. BL-ABSE, through complete NTT optimization based on negacyclic convolution, reduces polynomial multiplication from $O\left(n^2\right)$ to $O(nlogn)$, and achieves computational acceleration in all three phases of encryption, token generation, and search by combining precomputed tables of roots of unity, bit-reversal permutations, and Montgomery reduction.

The performance disadvantage of traditional approaches is particularly prominent in the permission revocation dimension. The revocation mechanism of Shen et al. [22] requires regenerating keys for all non-revoked users, with time complexity $O\left(\right|U_r\left|\right)·\mathsf{KeyUpd}$; when the system is large, revocation latency can reach the hour level. Yu et al. [26], with blockchain assistance for revocation, still require $O\left(\right|\mathsf{DB}\left|\right)$ bilinear pairing operations for data re-encryption. BL-ABSE reduces the time complexity of permission revocation to $O\left(1\right)$ using an on-chain revocation list mechanism—the revocation operation requires only one blockchain transaction (approximately 2 s for confirmation), without any data re-encryption or key redistribution. This advantage is particularly important in large-scale systems requiring frequent permission changes.

Combining the above analysis, BL-ABSE demonstrates significant advantages in both functional completeness and computational efficiency. On the functional level, BL-ABSE is the first to organically integrate lattice-based post-quantum security, attribute-based fine-grained access control, blockchain decentralized trust, immediate permission revocation, and tamper-evident audit logs into a unified framework. Its core design philosophy lies in migrating revocation state management from traditional cryptographic mechanisms (key updates or data re-encryption) to blockchain smart contracts, decoupling the cost of revocation from system scale. On the efficiency level, BL-ABSE controls the computational complexity of high-frequency search operations to $O(nlogn)$ through NTT optimization, while concentrating blockchain interactions on low-frequency management operations, achieving an effective balance between security and practicability.

6.4. Relationship Between Search Latency and Keyword Scale

Search latency is one of the most critical performance metrics for searchable encryption protocols in practical deployments, directly determining user query experience and system service quality. The $\mathsf{BC}\text{-}\mathsf{Search}$ algorithm (Algorithm 5) of BL-ABSE needs to traverse all index records in the encrypted database and perform RLWE commitment matching operations on each record; therefore, its search latency should theoretically increase linearly with the number of keyword indexes in the database. This experiment aims to validate this theoretical expectation through systematic empirical measurements, evaluating the search performance of the framework at different data scales, and providing quantitative references for capacity planning in actual deployments.

Experimental Setup

The experiment uses the RLWE parameter configuration consistent with the protocol design: lattice dimension $n=1024$, prime modulus $q=\mathrm{12,289}$ (satisfying $q\equiv 1\left(\mathrm{mod}2n\right)$ to support NTT), discrete Gaussian standard deviation $\sigma =3.2$, and commitment matching threshold $B=40$. This parameter combination guarantees a 128-bit post-quantum security level, comparable to the parameter choices of the CRYSTALS series constructions in the NIST post-quantum cryptography standardization process.

The experiment constructs an encrypted database with 100 to 50,000 keyword indexes, with 8 specific test scale gradients: 100, 500, 1000, 2000, 5000, 10,000, 20,000, and 50,000. Each keyword index is generated following the procedure of Algorithm 3 ($\mathsf{BC}\text{-}\mathsf{Encrypt}$): first, the public hash function $H_{\mathrm{seed}}$ is used to deterministically derive the Gaussian sampling seed from the keyword, and then the RLWE commitment is computed via NTT-optimized polynomial multiplication. The search phase executes the complete $\mathsf{BC}\text{-}\mathsf{Search}$ algorithm, including triple verification of token signature verification, on-chain policy and revocation status checking (in local cache mode), and RLWE commitment matching. To eliminate random fluctuations, each set of experiments is independently repeated 30 times; the average is taken as the final result, with minimum and maximum values recorded to assess result stability.

Results and Analysis

Figure 3 shows the experimental results of search latency varying with the number of keywords. The light blue shaded area represents the range from minimum to maximum search latency across 30 repeated experiments, and the red dashed line is the linear fit based on the empirical data.

The experimental results show that search latency and the number of keywords exhibit a highly linear growth relationship. When the database contains 100 keyword indexes, the average search latency is only 2.79 ms; as the number of keywords grows to 1000, 10,000, and 50,000, the average search latency increases to 29.29 ms, 290.32 ms, and 1443.79 ms, respectively.

Table 9. Search latency experimental data.

Keywords	Avg. (ms)	Std. (ms)	Min (ms)	Max (ms)	Per-Record (µs)
100	2.79	0.05	2.72	3.05	27.9
500	14.87	0.68	13.97	17.25	29.7
1000	29.29	1.03	28.23	32.62	29.3
2000	58.01	2.21	55.83	65.57	29.0
5000	146.53	5.70	139.35	163.34	29.3
10,000	290.32	9.17	280.22	325.56	29.0
20,000	576.35	19.78	544.40	631.12	28.8
50,000	1443.79	26.00	1361.24	1495.07	28.9

provides detailed measurement data for each scale gradient.

The linear fit results in Figure 3 show that the fitted line matches the empirical data points closely, with a fitted slope of 28.86 µs/keyword, indicating that each additional keyword index record increases search latency linearly by 28.86 µs. This result empirically validates the theoretical computational complexity $O\left(\right|\mathsf{DB}|·n)$ of the $\mathsf{BC}\text{-}\mathsf{Search}$ algorithm—search latency is strictly proportional to database size. Further analysis of per-record matching time in Table 9 shows that dividing the total search latency by the number of keywords for each group yields a stable average matching time per record of 27.9–29.7 µs, which does not vary with database size. This indicates that the single execution overhead of RLWE commitment matching operations—including polynomial coefficient difference computation, centered modular reduction, and Euclidean distance computation—is constant; the growth in search latency is entirely attributable to the increasing number of index records that need to be traversed.

From the perspective of result stability, the Min-Max shaded region in Figure 3 closely encloses the fitted line throughout, with limited variation between minimum and maximum values across experimental groups. Taking the 50,000-keyword scale as an example, the minimum value across 30 repeated experiments is 1361.24 ms, the maximum is 1495.07 ms, and the standard deviation is only 26.00 ms, with a coefficient of variation of approximately 1.8%. Smaller scale gradients exhibit even better stability; for example, at 100 keywords, the standard deviation is only 0.05 ms. This stability characteristic indicates that BL-ABSE’s search performance has good predictability, facilitating quality-of-service guarantees and resource scheduling in practical systems.

6.5. Permission Revocation Efficiency Comparison Experiment

Permission revocation latency is a core metric for evaluating the practicality of dynamic access control mechanisms, directly determining the security window during which a revoked user can continue to access sensitive data. This section quantitatively evaluates the revocation time overhead of BL-ABSE and four representative baseline approaches at different user scales through comparative experiments.

The experiment adopts a simulation modeling method, constructing performance models based on algorithm descriptions and empirical data from the published papers of each baseline approach. Baseline operation time values are derived from literature measurements in a typical server environment (2.4 GHz processor): one bilinear pairing operation takes 4.2 ms, lattice polynomial multiplication (naïve implementation) takes 401.4 ms, and Hyperledger Fabric PBFT consensus confirmation time is approximately 2000 ms. The experiment uses user scale $N\in \{100,500,1000,2000,5000,\mathrm{10,000},\mathrm{20,000},\mathrm{50,000}\}$ as the independent variable, simulating the typical scenario of revoking a single user ($r=1$). Each parameter group is independently repeated 30 times, with mean ± standard deviation as the final reported result. Comparison approaches include: Shen et al. [22] (lattice-based KUNodes key update), Wang et al. [28] (bilinear pairing key reissuance), Yu et al. [26] (blockchain-assisted proxy re-encryption), and Yin et al. [27] (blockchain records + key reissuance).

Figure 4 shows the permission revocation latency curves of the five approaches as user scale N grows from 100 to 50,000. Wang et al. [28] and Yin et al. [27] employ key reissuance mechanisms: after revoking one user, new private keys must be regenerated and securely distributed for all remaining $N-1$ legitimate users, with revocation time strictly linearly proportional to system scale. Wang et al. [28] have a revocation latency of approximately 3306 ms at $N=100$, which sharply increases to approximately 1,705,047 ms (about 28.4 min) at $N=\mathrm{50,000}$, an increase of more than 515×; Yin et al. [27] reach approximately 1,041,063 ms (about 17.4 min) at $N=\mathrm{50,000}$. During this period, revoked users can continue to access the system with old keys, creating a serious security window. Shen et al. [22] compress the revocation path to $O(logN)$ nodes using the KUNodes algorithm, with latency at $N=\mathrm{50,000}$ of approximately 6631 ms, significantly improved compared to key reissuance methods but still growing slowly with system scale. The proxy re-encryption approach of Yu et al. [26] shifts the revocation cost to the ciphertext level, requiring re-encryption of all affected ciphertexts, with latency at $N=\mathrm{50,000}$ of approximately 142,138 ms (about 2.4 min), also showing a sub-linear growth trend.

In contrast, BL-ABSE’s revocation latency remains highly stable throughout the entire test range. As shown in Figure 4a, the BL-ABSE curve appears as a nearly horizontal line; over the range $N=100$ to $N=\mathrm{50,000}$, the mean value is consistently maintained in the interval of 2019 ms to 2065 ms, with a maximum fluctuation of only about 2.3%, empirically validating the $O\left(1\right)$ revocation complexity proved in Theorem 9. This scale-independent property stems from BL-ABSE’s decoupling of access control state from ciphertexts and migrating it to on-chain blockchain management: the revocation operation degenerates into submitting one on-chain transaction to the AccessControl smart contract, which takes effect immediately for all nodes after PBFT consensus confirmation (approximately 2 s), without requiring any data re-encryption or key redistribution. The revocation latency consists only of three scale-independent constant terms: consensus mechanism (approximately 2000 ms), contract execution (approximately 1 ms), and node cache synchronization (approximately 50 ms).

Simulation Methodology Transparency. The above comparison experiment adopts simulation modeling, with baseline operation parameters derived from published measurements: bilinear pairing time (4.2 ms) from the benchmarks reported in [28]; lattice polynomial multiplication (401.4 ms, naïve implementation) from our own Table 6 measurement; Hyperledger Fabric PBFT consensus confirmation (∼2000 ms) from the default Fabric configuration [19]. Since different hardware platforms may produce different absolute timing values, we emphasize that the asymptotic complexity difference between schemes—$O\left(N\right)$ for key-reissuance schemes, $O(logN)$ for KUNodes, and $O\left(1\right)$ for BL-ABSE—is hardware-independent and constitutes the fundamental advantage.

End-to-End Revocation Latency Decomposition

To address the concern that the reported ∼2-s revocation latency may only reflect blockchain confirmation time rather than the true end-to-end enforcement delay, we decompose the complete revocation pipeline into six stages and measure each independently. The six stages are: (T0 → T1) transaction submission to the ordering service; (T1 → T2) PBFT three-phase consensus; (T2 → T3) smart contract state update; (T3 → T4) blockchain event broadcast to peer nodes; (T4 → T5) local cache synchronization at edge nodes; (T5 → T6) first search request rejection (end-to-end verification).

Figure 5 presents the decomposition results under three experimental dimensions. Key findings are as follows.

Revocation list size has negligible impact. As the number of existing revocation entries grows from 0 to 10,000, the total end-to-end latency remains stable at approximately 2200 ms ($\pm 56$ ms), confirming the $O\left(1\right)$ complexity of the revocation operation. The smart contract execution stage shows a marginal increase (from ∼1.0 ms at 0 entries to ∼11 ms at 10,000 entries), but this remains negligible relative to the PBFT consensus time.

Concurrent search load causes moderate degradation. Under 500 concurrent search requests, the total latency increases to approximately 2398 ms (an ∼8% increase over the zero-load baseline of 2219 ms). The increase is primarily attributable to queuing delays in the ordering service. Even under this high-load scenario, the end-to-end latency remains well below 3 s.

Node count has a small linear effect. Increasing the consortium from 3 to 7 nodes adds approximately 140 ms of total latency (from ∼2146 ms to ∼2285 ms), reflecting the increased message complexity of PBFT consensus with more participants ($O\left(n^2\right)$ messages per consensus round).

Figure 6 shows the trend lines with error bars. The dominant component in all configurations is the PBFT consensus stage, which accounts for approximately 93% of the total end-to-end latency. The remaining stages (transaction submission ∼40 ms, contract execution ∼1–11 ms, event broadcast ∼22 ms, cache synchronization ∼60 ms, search rejection ∼0.07 ms) collectively contribute only ∼7%. This confirms that the reported ∼2-s revocation latency is indeed an accurate representation of the end-to-end enforcement delay, not merely the consensus confirmation time.

6.6. Threshold B Verification Experiment

To rigorously validate the choice of threshold $B=40$ in the commitment matching mechanism (Section 4.11), we conduct large-scale experiments measuring the distance distribution for both matching and non-matching keyword pairs.

Experimental Design. We generate 1000 matching keyword pairs (same keyword used for both encryption and search) and 10,000 non-matching keyword pairs (different keywords). For each pair, we compute the RLWE commitment using the full pipeline (hash-seed derivation, deterministic Gaussian sampling, NTT-based polynomial multiplication) and measure the centered Euclidean distance.

Results. Figure 7a shows that the distance distribution exhibits a stark bimodal pattern: all 1000 matching pairs produce $\mathsf{dist}=0$ (strictly zero, no false negatives), while non-matching pairs have distances concentrated around $1.29\times {10}^{10}$ with a minimum of $1.14\times {10}^{10}$. The safety margin between $B=40$ and the minimum non-matching distance is approximately $2.85\times {10}^8$ (Figure 7b). No false positives are observed even when B is artificially increased to ${10}^9$, confirming that $B=40$ is extremely conservative.

Parameter Sensitivity. Figure 8 shows that varying $\sigma \in \{2.0,3.2,4.0,6.0\}$ has minimal impact on the non-matching distance distribution (∼1.29 $\times {10}^{10}$ across all values), with zero false positives in all cases. This demonstrates that the threshold $B=40$ is robust across the practical range of Gaussian parameters and the choice is not sensitive to implementation-level variations in the sampling process.

6.7. Blockchain Throughput Stress Test

While the preceding experiments demonstrate the efficiency of BL-ABSE’s cryptographic operations, the blockchain layer may become a bottleneck under high-concurrency scenarios. This section evaluates the throughput and latency characteristics of the blockchain layer under varying loads.

Experimental Design. We simulate three types of blockchain transactions— RevokeAccess, RegisterPolicy, and AuditLog—at send rates ranging from 10 to 500 TPS, measuring the actual throughput, mean latency, tail latency (P95, P99), and failure rate. Tests are conducted with 3, 5, and 7 consortium nodes.

Results. Figure 9a shows that the blockchain sustains near-ideal throughput up to approximately 200 TPS, beyond which queuing delays cause gradual degradation. At 500 TPS, the actual throughput for RevokeAccess transactions is 489 TPS with a 2.11% failure rate (Figure 9c). The three transaction types exhibit similar performance profiles, indicating that contract complexity differences are negligible compared to consensus overhead.

The maximum sustainable throughput (defined as the highest send rate with <5% failure rate) is approximately 490 TPS for the 5-node configuration. This is sufficient for practical deployments: even a system processing 100 revocations and 1000 search queries per second would require only ∼100 TPS of blockchain throughput (since search queries use local cached permission checks and do not generate on-chain transactions).

Figure 10 shows that increasing the node count from 3 to 7 has less than 3% impact on maximum sustainable throughput, confirming that the PBFT message complexity overhead is manageable at the consortium scales considered in this paper.

6.8. Search Pattern Leakage Quantification

To complement the theoretical leakage analysis in Section 5.8, we experimentally quantify the effectiveness of three attack strategies against BL-ABSE’s deterministic commitment mechanism.

6.8.1. Frequency Analysis Attack

Figure 11 presents the keyword recovery rate under the frequency analysis attack. We simulate keyword queries following a Zipf distribution with skewness parameter $\alpha$ and measure the adversary’s ability to match observed commitment frequencies to the known keyword distribution. Key observations include: (1) larger vocabulary sizes significantly reduce recovery rates (from 14.9% at $\left|\mathcal{W}\right|=100$ to 2.5% at $\left|\mathcal{W}\right|=1000$ for $\alpha =1.0$ with 10,000 queries); (2) higher skewness ($\alpha =2.0$) can increase recovery rates for small vocabularies but actually decreases them for large vocabularies (as only a few keywords are observed); (3) increasing the number of observed queries improves the attack, but the improvement saturates once the adversary has observed all unique keywords.

6.8.2. Dictionary Attack and Cross-User Linkage

Figure 12a confirms the theoretical prediction: when the adversary’s dictionary covers the actual keyword space, 100% identification is achieved. This is an inherent property of all deterministic searchable encryption protocols—the defense lies in using a sufficiently large and unpredictable keyword space. Figure 12b shows that cross-user linkage is complete: all user pairs sharing at least one keyword are linkable (100% linkage rate), with an average of ∼20 shared keywords per pair. These results quantify the privacy cost of the deterministic commitment design and motivate the ORAM-based mitigation discussed in Section 7.2.

6.9. Communication and Storage Overhead Analysis

To provide a complete picture of BL-ABSE’s practical resource requirements, we analyze the communication overhead per operation and the storage scaling behavior.

Table 10. Core Data Structure Sizes ($n=1024$, $q=12,289$).

Data Structure	Size (Bytes)	Notes
Commitment ($\mathsf{commit}$)	1792	$n\times \lceil {log}_{2}q\rceil /8$
Search Token ($T_w$)	1936	commit + attrs + timestamp + signature
Encrypted Index (I)	1878	commit + policyHash + CID + timestamp
ABE Ciphertext (5 attrs)	1664	$(2\times |\mathsf{attrs}|+3)\times 128$ B
ABE Ciphertext (10 attrs)	2944	Scales linearly with policy size
User Private Key (5 attrs)	832	Attribute set + ABE key components
RevokeAccess TX	328	Minimal on-chain footprint

shows that the dominant data structure is the RLWE commitment (1792 bytes), which determines the size of both search tokens and encrypted indices. The commitment size is a direct consequence of the lattice dimension $n=1024$; reducing n would decrease this overhead but at the cost of security strength.

Figure 13a shows the storage scaling behavior. At 100,000 documents, the total storage is approximately 1.22 GB, of which 114.9 MB is on-chain (policy hashes, CIDs, revocation records, audit logs) and 1.11 GB is off-chain (IPFS-stored ciphertexts). The on-chain storage scales linearly at approximately 1.15 KB per document, which is within the practical limits of consortium blockchains.

Figure 14 summarizes the per-operation communication overhead. The most expensive operation is BC-Encrypt with 10 attributes and 100 KB data (∼103 KB total), which is dominated by the IPFS upload of the encrypted data itself. High-frequency operations have modest overhead: BC-Search with 10 results requires only ∼2.4 KB (token submission + CID list), and RevokeAccess requires only 328 bytes. The Trapdoor operation is entirely local and incurs zero communication cost.

7. Conclusions and Future Work

In response to the systematic limitations of cloud storage ciphertext retrieval in four dimensions—post-quantum security, decentralized trust, dynamic permission management, and operational auditing—this paper proposes the BL-ABSE framework, with lattice-based cryptography as the security foundation and the blockchain as the trust enhancement layer, constructing a ciphertext retrieval architecture that combines quantum-attack resistance, immediate permission revocation, and full lifecycle auditing.

On the theoretical level, this paper proposes a deterministic keyword commitment mechanism based on RLWE and achieves $O(nlogn)$ complexity through NTT optimization; designs a $(t,n)$ threshold key protocol combined with zero-knowledge proofs to secure collaborative key generation, with formal analysis of the PBFT–threshold parameter relationship (Lemma 1); implements $O\left(1\right)$ immediate revocation using smart contracts; and rigorously proves six security properties under the QPT adversary model with clear delineation of proof scope (Table 4). On the experimental level, the prototype system validates the NTT acceleration effect, the linear law of search latency, the scale-independence of revocation latency (with end-to-end decomposition in Section End-to-End Revocation Latency Decomposition), the conservative safety of threshold $B=40$ (Section 6.6), the blockchain throughput capacity of ∼490 TPS (Section 6.7), the quantitative characterization of search-pattern leakage (Section 6.8), and the practical communication/storage overhead (Section 6.9).

7.1. Limitations

We acknowledge the following limitations of the current framework. First, the deterministic commitment design inherently leaks the search pattern, enabling frequency analysis, dictionary attacks, and cross-user linkage as quantified in Section 6.8. While this is a common property of non-interactive searchable encryption protocols, it represents a concrete privacy cost. Second, the Attribute Authority (AA) remains a centralized trust component; a compromised AA could issue fraudulent attribute certificates, undermining the access control layer despite the decentralized key management. Third, the current framework supports only single-keyword exact matching; multi-keyword conjunctive or range queries are not supported. Fourth, the security proofs rely on the random oracle model for hash functions H and $H_{\mathrm{seed}}$; standard-model proofs would provide stronger theoretical guarantees. Fifth, the revocation experiment in Section 6.5 uses simulation modeling for baseline comparisons, and absolute timing values may differ across hardware platforms, though the asymptotic complexity differences are hardware-independent.

7.2. Future Directions

First, multi-keyword conjunctive query support. The current framework only supports single-keyword exact matching, whereas practical scenarios have urgent needs for complex predicates such as boolean queries and range queries. Constructing predicate encryption protocols supporting multi-keyword conjunctions within the RLWE framework, while maintaining $O(nlogn)$ efficiency and post-quantum security reductions, is the core direction for future work.

Second, security proofs in the standard model. The security proofs in this paper rely on the random oracle model; lattice-based security reductions in the standard model have stronger theoretical rigor. Exploring adaptively secure constructions that maintain practical efficiency will be an important theoretical advancement direction.

Third, enhanced privacy for access and search patterns. As quantified in Section 6.8, BL-ABSE’s deterministic commitments leak the search pattern. Integrating Oblivious RAM (ORAM) techniques could eliminate search-pattern leakage at the cost of $O(logN)$ additional communication per query. Alternatively, applying differential privacy mechanisms to inject controlled noise into query patterns could mitigate the effectiveness of frequency analysis attacks while preserving acceptable search accuracy. Both directions require careful analysis of the interaction between the lattice-based cryptographic layer and the privacy-enhancement layer.

Fourth, decentralized attribute management. Extending the threshold decentralization from key management to attribute certification (e.g., multi-authority ABE or blockchain-based decentralized identity) would eliminate the AA single-point-of-trust limitation discussed in (Section 3.2.3).

Fifth, hardware acceleration and adaptation for resource-constrained devices. The computational capacity of IoT terminals and wearable devices is far below that of general-purpose servers. Efficiently adapting NTT and discrete Gaussian sampling to ARM microcontrollers or accelerating them with FPGAs, and interfacing with the hardware ecosystem of NIST post-quantum cryptography standards (FIPS 203/204/205 [13,14,15]), are key engineering directions for promoting widespread deployment of the framework on edge devices.