Traceable and Revocable Broadcast Encryption Scheme for Preventing Malicious Encryptors

Abstract

Under the paradigm of the Internet of Things (IoT), the processing of large-scale data not only imposes higher demands on data-sharing efficiency but also increases the risk of user privacy leakage. To address these challenges, this paper proposes a blockchain-assisted traceable and revocable broadcast encryption scheme for preventing malicious encryptors (BATR). To resist trapdoor attacks by malicious encryptors, the scheme utilizes the uniform distribution property of hash function outputs to generate the random numbers required for the encryption algorithm. To block malicious users from leaking private keys, which attackers could exploit to construct piracy decoders with decryption capabilities, the scheme enhances the traditional broadcast encryption system by incorporating public tracing and revocation mechanisms. The scheme employs personalized transmission technology, allowing data owners to share public data with a set of authorized users while also sharing personalized data with specific authorized users. Additionally, users communicate using pseudonyms to ensure that their real identities are not accessible to third parties, thereby meeting privacy protection requirements. With the assistance of blockchain, trusted authorities and users can invoke smart contract interfaces to trigger blockchain peer nodes to execute smart contracts, thereby acquiring or updating identity authentication information stored on the blockchain to achieve secure authentication. This paper provides an analysis of the correctness and security of BATR, demonstrating that BATR satisfies chosen-ciphertext security under the Random Oracle Model. We also present performance evaluations and describe the experimental setup used to obtain operation-time baselines. Finally, this paper conducts a performance analysis of the BATR scheme, which exhibits high computational efficiency and compact communication bandwidth, resulting in significant performance improvements.

1. Introduction

In recent years, broadcast encryption (BE) [1] has seen extensive adoption across diverse domains including IoT, electronic healthcare and satellite radio communications. Broadcast encryption enables a broadcaster to securely encode messages and distribute the ciphertext to a group of authorized users. However, in some practical BE application scenarios, broadcasting not only requires sending common broadcast information but also needs to deliver personalized messages to individual users. To address this issue, Ohtake [2] first proposed the concept of personalized transmission, known as Data Outsourcing with Simultaneous Individual Transmission (DOSIT). Each authorized user can utilize their private key to access both publicly shared data and personalized content.

However, some authorized users may exhibit malicious behavior. Malicious users might leak private keys to attackers for illicit gains, enabling the latter to forge decryption-capable pirate decoder by using these private keys. Traitor tracing is designed to prevent such scenarios [3]. Upon detecting pirated decryption devices, the mechanism interacts with it to ultimately trace the malicious users involved in constructing the pirate decoder. Additionally, when the access rights of malicious users are revoked, regenerating ciphertext and keys requires substantial computational resources. Therefore, it is also essential to develop efficient revocation mechanisms.

If we regard the traitor tracing system as the protocol jointly operated through the data provider, the encryptor, the decryptor, the tracer, and the pirate decoder, then we must also evaluate the threat of trapdoor attacks embedded by malicious encryptors [4]. Since the encryptor is not always aligned with the digital content provider, we should consider the existence of this attack model in the real application of broadcast encryption. On the one hand, paying authorized subscribers can normally decrypt ciphertext using their private keys; on the other hand, the encryptor may leak trapdoors to attackers, who can then use simple attacks to obtain the plaintext underlying the broadcast ciphertext.

If the encryptor exhibits malicious behavior, traditional traitor tracing systems may fail to function properly in such scenarios. This is because the pirate box constructed by the attacker is not composed of private keys from authorized users but rather of trapdoors embedded by the malicious encryptor. In this case, the set of malicious users output by the traditional traitor tracing system would be empty, leading to tracing failure. Therefore, designing an efficient traitor tracing system to prevent malicious encryptors holds significant theoretical importance and practical application value.

In 2008, the emergence of blockchain-based digital currency, also known as Bitcoin, made the application of blockchain technology to IoT feasible. As a decentralized ledger, blockchain features distribution, traceability and tamper-resistance. Nodes jointly preserve the ledger through consensus protocols to guarantee data integrity [5]. As a result, blockchain surpasses commonly used cloud and database systems in aspects such as resistance to tampering, privacy preservation, and identity authentication [6]. Secondly, the full-node synchronization and real-time updating of transaction information in the blockchain ensure information transparency. The transparency and traceability inherent in blockchain allows transaction records to be viewed in real time. Multiple blockchain peer nodes can jointly manage the blockchain, ensuring that all users must register on the blockchain, thereby providing a unified identity authentication service. Operations related to user identity verification are written into smart contracts. Meanwhile, users and trusted institutions can invoke corresponding smart contract interfaces (APIs) to retrieve or update information stored on the blockchain, achieving secure authentication.

Unlike traditional centralized databases or cloud storage systems that rely on a single trusted administrator and thus suffer from a single point of failure, the blockchain in BATR serves as a decentralized and tamper-resistant Authentication Information Ledger (AIL). This design is particularly important under our threat model, because malicious entities may attempt to covertly modify or delete authentication, tracing, or revocation records. By leveraging multi-node consensus and ledger immutability, blockchain ensures that these records remain publicly verifiable and non-forgeable, which cannot be guaranteed by conventional centralized platforms.

1.1. Contributions

This paper introduces a blockchain-assisted traceable and revocable broadcast encryption scheme for preventing malicious encryptors (BATR). The main contributions of this paper are as follows:

(1)

BATR ensures resistance against malicious encryptors attacks and supports personalized message transmission, while user keys are jointly generated by users and a trusted authority, thereby avoiding key escrow issues and certificate management problems. Additionally, users communicate using pseudonyms to ensure that their real identities are not accessible to third parties, meeting the requirements for privacy protection.

(2)

With the assistance of blockchain, the scheme supports a dual tracing mechanism. When a data breach occurs, access records stored on the blockchain can be used to identify malicious users. In cases where user private keys are compromised, the tracking algorithm can be used to interact with the pirate decoder to get the malicious user information. Without compromising the decryption functionality of other legitimate users, BATR supports the dynamic revocation of malicious users’ access rights through de-anonymization.

(3)

The trusted authority and users can invoke smart contract interfaces to trigger blockchain peer nodes to execute smart contracts, enabling the retrieval or updating of identity authentication information stored on the blockchain, thereby achieving secure authentication.

(4)

BATR has a fixed decryption cost and storage overhead. Additionally, the scheme features compact communication bandwidth and high computing efficiency.

1.2. Related Works

The framework for broadcast encryption was initially formulated by Fiat and Naor [1] in 1994, aiming to address secure communication issues in multi-user environments. Boneh et al. [7] firstly utilized bilinear maps to propose a black-box traitor tracing scheme resistant to full collusion attacks, which can withstand collusion attacks from all unauthorized users. In recent years, anonymous broadcast encryption systems have garnered significant attention. Barth et al. [8] proposed for the first time a selective secure anonymous broadcast encryption scheme whose computing cost and communication bandwidth are linearly related to the number of system users. Additionally, they provided a generic construction achieving chosen-ciphertext security and receiver anonymity. Fazio and Perera [9] introduced the Outsider Anonymous Broadcast Encryption (OAnoBE) concept within the BE revocation framework, ensuring security under a non-standard Random Oracle Model (ROM). Outsider anonymity refers to the inability of external observers to determine the set of users included as recipients of the ciphertext, even if multiple unauthorized users collude. Lai et al. [10] employed revocation techniques to design a revocable anonymous identity-based broadcast encryption scheme, but its decryption cost grew with the number of users.

Integrating personalized transmission technology, Mandal et al. [11] constructed an outsider anonymous DOSIT scheme. This scheme features constant decryption costs, but the size of user private keys scales linearly with the total number of users, making it unsuitable for storage on resource-constrained smart devices. Yao et al. [12] proposed a fully anonymous blockchain-assisted privacy-preserving transaction scheme, achieving anonymity even among authorized users. Additionally, this scheme improved upon traditional DOSIT frameworks, addressing the key escrow issue.

Chor [3] first introduced the concept of traitor tracing at Crypto94, aiming to assist content publishers in identifying piracy. Kiayias et al. [13] integrated the traitor tracing mechanism into broadcast encryption systems, enabling efficient tracing of malicious users. Libert et al. [14] proposed a traitor tracing scheme supporting anonymity, which achieves efficient tracing while protecting user privacy; however, this scheme does not consider the revocation mechanism for malicious users’ permissions. Mandal et al. [15] introduced a fully anonymous tracing and revocation scheme that satisfies adaptive chosen-ciphertext security, but its decryption cost grows with the number of receivers.

Nevertheless, none of the aforementioned traitor tracing schemes can resist trapdoor attacks embedded by malicious encryptors. The concept of malicious encryptors embedding trapdoor attacks was first introduced by Wang and Pan et al. [4] in 2023, where attackers can use simple attacks to obtain the plaintext underlying the broadcast ciphertext. Under such attacks, traditional traitor tracing systems output an empty set of malicious users, leading to tracing failure. By improving the traitor tracing scheme in [7], their work constructed a traitor tracing scheme resistant to malicious encryptor attacks, but this scheme does not consider the anonymity of authorized users. In 2024, Liu and Pan et al. [16] proposed a traceable and revocable broadcast encryption scheme by considering the existence of malicious encryptors and incorporating personalized transmission technology. This scheme uses pseudonym technology to protect the real identities of authorized users and satisfies chosen-plaintext security. In the same year, Liu and Hu et al. [17] employed puncturing techniques to implement the revocation of malicious users’ permissions, but this scheme has high computing cost and communication overhead. In 2025, Liu and Hu et al. [18] introduced an anonymous traitor tracing scheme based on puncturable encryption, assisted by blockchain and the Interplanetary File System (IPFS). This scheme addresses data storage issues by combining blockchain with IPFS, achieving storage scalability. However, both decryption overhead and private key size grow with the number of receivers.

1.3. Organization

Section 2 introduces the fundamental knowledge of mathematics and cryptography. Section 4 details BATR’s system architecture and security model. Section 4 elaborates its concrete implementation structure. Section 5 provides proofs of the correctness and security. Section 6 presents the performance evaluation. To conclude, we provide an overview of our work.

2. Preliminary Backgrounds

2.1. Notations

Table 1. Notations.

Notations	Meaning
$\lambda ,\eta$	Security parameter
N	Total number of receivers
$mpk$	System public key
$msk$	System secret key
$I{D}_i$	User identity
$p{k}_i$	$I{D}_i$’s public key
$s{k}_i$	$I{D}_i$’s private key
$PI{D}_i$	$I{D}_i$’s pseudonym
${\left\{H_i\right\}}_{i=1}^7$	Hash functions
S	A set of receive users
m	Common message
l	The bit length of message
K	Public Session Key
$K_i$	Personalized Session Key
$TA$	Trusted Authority
$TT$	Tracing entity
$EN$	Endorsing Node
$CT$	Broadcast ciphertext
$ST$	A set of traitors
$ON$	Ordering Node
$AIL$	Authentication Information Ledger
${\mathrm{TID}}_i$	Tracing identity tag of user $u_i$
$Hdr$	ciphertext header
$DOSIT$	Data Outsourcing with Simultaneous Individual Transmission

presents the notations and their corresponding meanings utilized in this paper.

2.2. Bilinear Pairings

Given two multiplicative cyclic groups G and $G_T$ of order p, where g is the generator of G. If the following properties are satisfied, then $e:G\times G\to G_T$ is called a bilinear map.

1.

Bilinearity: $\forall x,y\in G$, $\forall a,b\in Z_p$, $e\left(x^a,{\mathrm{y}}^b\right)=e{\left(x,y\right)}^{ab}$;

2.

Non-degeneracy: $e(x,y)$ is the generator of $G_T$ and $e(g,g)\ne 1$;

3.

Computability: The function e can be evaluated efficiently.

2.3. Cryptographic Hash Function

Hash functions [19] have the following attributes:

1.

Unipolarity: Given a hash value y, the probability of finding an input x such that $H\left(x\right)=y$ is negligible;

2.

Weak collision resistance: Given a hash value $H\left(x_1\right)$, the probability of finding an input $x_2$ and $x_2\ne x_1$ such that $H\left(x_2\right)=H\left(x_1\right)$ is negligible;

3.

Strong collision resistance: The probability of finding two different inputs $x_1$ and $x_2$ such that $H\left(x_1\right)=H\left(x_2\right)$ is negligible.

2.4. Zero-Knowledge Protocol

In Zero-Knowledge Proof (ZKP) protocols [20], the prover P can demonstrate to the verifier V a statement’s validity without revealing any information beyond its truth. Assuming $ZK\{(d_1,d_2):A=e{(g,h)}^{d_2}\wedge e(d_1,h^{\prime })=A^{-1}·B\}$ is a ZKP protocol, the public input for this statement is $(PG,g,h,h^{\prime },A,B)$, and $d_1$ and $d_2$ satisfy the equations $A=e{(g,h)}^{d_2}$ and $e(d_1,h^{\prime })=A^{-1}$.

In this paper, a Zero-Knowledge Proof of Knowledge (ZK-PoK) for discrete logarithms is used, wherein the prover P can demonstrate to the verifier V the possession of a specific group element’s discrete logarithm without disclosing any additional information. The efficient ZK-PoK protocol is presented in Figure 1 [21], where P possesses $(g,x,R)$ and aims to demonstrate to V, who holds $(g,R)$, that $R=g^x$ belongs to the multiplicative group G generated by g.

2.5. Complexity Assumption

The security of our scheme relies on the truncated decisional q-augmented bilinear Diffie–Hellman exponent assumption (q-ABDHE) [22]. Let G and $G_T$ be multiplicative cyclic groups of prime order p, g and $g^{\prime }$ are two different generators of G. A bilinear map $e:G\times G\to G_T$ is established. Randomly select $\alpha \in Z_p$, then publish the vector $P_{g,\alpha ,g^{\prime }}=(g,g^{\alpha },g^{{\alpha }^2},\dots ,g^{{\alpha }^q},g^{\prime },{g^{\prime }}^{{\alpha }^{q+2}})\in G^{q+3}$ and an element $T\in G_T$.

Given a probabilistic polynomial-time algorithm that accepts the public parameter vector $P_{g,\alpha ,g^{\prime }}=(g,g^{\alpha },g^{{\alpha }^2},\dots ,g^{{\alpha }^q},g^{\prime },{g^{\prime }}^{{\alpha }^{q+2}})\in G^{q+3}$ and the element $T\in G_T$, it determines whether $T=e{(g,g^{\prime })}^{{\alpha }^{q+1}}$ or T is a uniformly random element Z in $G_T$. The success probability in solving the qq-ABDHE challenge is defined in Equation (1)

$$Ad{v}^{q-ABDHE}\left(\lambda \right)=\left|Pr\left[B{({\mathcal{P}}_{g,\alpha ,g^{\prime }},e(g,g^{\alpha }))}^{{\alpha }^{q+1}}\right]=1\right|-Pr[B({\mathcal{P}}_{g,\alpha ,g^{\prime }},T)=1]\left|\ge \epsilon \right.$$

(1)

Definition 1.

The truncated decisional q-ABDHE assumption holds if no PPT algorithm can solve the problem defined in Equation (1) with non-negligible advantage.

2.6. Tardos Codes

The tracing mechanism of BATR is based on the Tardos fingerprint code framework [23]. This framework consists of two core algorithms, which are described in detail as follows:

1.

$(\Gamma ,WatMTK)\leftarrow CodeGen\left(1^{\eta },N\right)$: Input a safety parameter $\eta$ and an integer $N=poly\left(\eta \right)$, the algorithm selects an error tolerance $\epsilon \in (0,1)$ and a maximum collusion threshold $L=poly\left(\eta \right)\le N$ to set $k=⌈log\left({\displaystyle \frac{1}{\epsilon }}\right)⌉$ and the code word length $l=100L^{2}k$. It uniformly and randomly selects $r_i$ from $\left[t^{\prime },{\displaystyle \frac{\pi }{2}}-t^{\prime }\right]$ with $0<t^{\prime }<{\displaystyle \frac{\pi }{4}}$ and ${sin}^2{t}^{\prime }=t$. A matrix $C_{N\times l}$ is generated, where any elements $c_{ji}$ and $c_{j^{\prime }i}$ with $j\ne j^{\prime }$ exhibit significant positive correlations, and the elements in the matrix tend to 1 when $X_i$ surpasses a predefined threshold. The code book $\Gamma ={\left\{w_j\right\}}_{j=1}^N$ is constructed, where $w_j\in {\left\{0,1\right\}}^l$ represents the j-th row of code matrix $C_{N\times l}$. The watermarking master tracing key is $WatMTK=(Z,{\left\{X_i\right\}}_{i=1}^l)$.

2.

$\left(T\right)\leftarrow Identify(WatMTK,w)$: Input the master tracing key $WatMTK=(Z,{\left\{X_i\right\}}_{i=1}^l$ and a pirated code word w of length l. Let $S={\left\{w_j\right\}}_{j=1}^L(\in \Gamma )$ denote the set of colluders, and $F\left(S\right)$ represents the feasible set of S containing w. The condition satisfied by $F\left(S\right)$ is as follows: for $w_j\left[i\right]=b\in \left\{0,1\right\}$, it holds that $w\left[i\right]=b$, where $1\le i\le l$, and $w_j\left[i\right]$ and $w\left[i\right]$ denote the i-th bit of $w_j\in S$ and $w\in {\left\{0,1\right\}}^l$ respectively. The algorithm retrieves ${\left\{X_i\right\}}_{i=1}^l$ from the master tracing key to generate a matrix $M_{N\times l}$,where the random variables $m_{ji}$ are independent with an expected value of 0 and a variance of 1, as defined in Equation (2).

$$m_{ji}=\left\{\begin{array}{cc}\sqrt{{\displaystyle \frac{1-X_i}{X_i}}},\hfill & \mathrm{if}{w}_j\left[i\right]=1\hfill \\ -\sqrt{{\displaystyle \frac{X_i}{1-X_i}}},\hfill & \mathrm{if}{w}_j\left[i\right]=0\hfill \end{array}\right.$$

(2)

Additionally, the algorithm extracts Z from WatMTK and evaluates whether the score computed via Equation (2) satisfies the threshold inequality ${\displaystyle \sum _{i=1}^l}w\left[i\right]·m_{ji}>Z$ holds. If the inequality is satisfied, the code word $w_j\in S$ is considered to have participated in the creation of the pirated code word $w\in F\left(S\right)$. The algorithm ultimately outputs the set of colluders T.

3. System and Security Models

3.1. System Model

As Figure 2 shows, the BATR scheme comprises multiple entities: trusted authority, authorized users, broadcasters, the tracer, blockchain, and smart contracts.

1.

Blockchain Nodes: Within blockchain systems, peer nodes are classified into two types: endorsing nodes (ENs) and ordering nodes (ONs). Endorsing nodes are primarily responsible for maintaining a complete copy of the distributed ledger and executing smart contracts. Specifically, ENs perform the following key functions: first, ENs validate the integrity of new blocks before they are appended to the blockchain; second, ENs receive transaction proposals from users and TA, execute the corresponding smart contract interfaces, and return the authenticated proposal responses to the requesters. Ordering nodes are responsible for transaction ordering and the generation of new blocks. Their main functions include collecting all validated transactions from ENs, ordering the transactions according to a predefined consensus algorithm, and packaging the ordered transactions into new blocks. This process ensures the eventual consistency of the blockchain network, meaning that all ENs maintain synchronized and consistent copies of the blockchain.

2.

Smart Contracts: The Authentication Information Ledger (AIL) is utilized to implement authentication services, storing and managing relevant data such as the pseudonyms, $TI{D}_i$, $p{k}_i$, and public key expiration times of legitimate users $u_i$. The smart contract system includes four core API interfaces: saveInfo, deleteInfo, updateInfo, and queryInfo. saveInfo is exclusively accessible to TA and is used to write new identity authentication information into the AIL; deleteInfo is invoked by TA when a user is detected as disconnected or identified as a malicious node, removing the corresponding record from the AIL; updateInfo is called by TA to update public information such as user public keys, with all pseudonyms requiring periodic updates to ensure the timeliness of key information; queryInfo is open to all users, supporting queries for other users’ public keys and pseudonyms. Among these, saveInfo, deleteInfo, and updateInfo are only accessible to TA, and any invocation requests from ordinary users are automatically rejected by the smart contract. The execution of these APIs triggers state changes in the AIL, and the results are broadcast to all valid users through an event mechanism, ensuring global consistency of the system state. As a query interface, queryInfo returns results only to the requester, implementing fine-grained access control. In BATR, blockchain is not used merely as a generic storage platform. It serves as the infrastructure for maintaining the Authentication Information Ledger (AIL), which stores pseudonyms, public keys, registration information, key-update events, and revocation records. This design is necessary in our threat model. If such records were maintained by a traditional centralized database or cloud server, the system would have to rely on a fully trusted administrator, and a compromised or colluding server could secretly modify, delete, or selectively hide critical records. By contrast, blockchain provides decentralization, tamper resistance, traceability, and consensus-based consistency, thereby ensuring that authentication-related records remain auditable, verifiable, and non-forgeable.

3.

Trusted Authority (TA): Responsible for system setup, generating system public parameters, and completing user registration. Upon successful registration, TA invokes the corresponding smart contract APIs to upload user information to the AIL. When a user is disconnected or detected for malicious behavior, TA calls the API to remove the corresponding record.

4.

Authorized Users: After the user sends a registration request to TA, TA generates a pseudonym, public key, and partial private key. After obtaining the partial private key, the user completes subsequent private key generation process. Authorized users can decrypt broadcast ciphertexts by leveraging their assigned private keys, thereby obtaining the public broadcast message and the corresponding personalized message. This entity is untrusted and may leak the private key to attackers, who could then construct a decryption-capable pirated decoder.

5.

Broadcasters: Used to generate and store broadcast ciphertexts for data owners, supporting personalized transmission. The tracing algorithm in BATR is of the public tracing type, so broadcasters can assume the role of the tracer.

6.

Tracer (TT): If there is a data breach, TT can detect suspicious users by analyzing data access records within blockchain based systems, identify their pseudonyms, and send them to TA; when a pirated box is detected, TT executes the tracing algorithm to interact with the pirated decoder, trace malicious users, and submit malicious users to TA, which then revokes their decryption permissions.

3.2. Working Flow

As Figure 3, the process by which TA invokes the API to complete the update of AIL records is as follows. Firstly, TA requests to call the updateInfo through the smart contract and sends a transaction request to its nearby endorsing nodes. Secondly, these endorsing nodes verify whether the requester has the authority to modify user information. If authorized, the endorsing nodes execute the smart contract to generate a processing result, which is then returned via the API interface. Thirdly, once the TA collects a sufficient number of responses, it forwards the authenticated transaction proposals to the ordering nodes for validity verification. After completing the verification, the ordering nodes package the legitimate transactions into a new block and broadcast it to all endorsing nodes. Each endorsing node performs integrity verification on the received block. If the verification is successful, the block is added to the blockchain, and the AIL state is updated according to the transaction types within the block. Finally, these changes are disseminated to all valid users to ensure that they update their cached authentication information.

3.3. Formal Definition

As shown in Figure 4, BATR incorporates six algorithms: Setup, KeyGen, Enc, Dec, $Trac{e}^D$ and $Revok{e}^D$.

1.

$\left(mpk,msk\right)\leftarrow Setup\left(\lambda \right)$: TA executes this algorithm with a security parameter $\lambda$ to generate the system master public key $mpk$ and the system master private key $msk$.

2.

$\left(s{k^{\prime }}_i,p{k}_i\right)\leftarrow KeyGen\left(mpk,msk,I{D}_i\right)$: TA inputs $mpk$, $msk$ and the identity information $I{D}_i$ of the user $u_i$, generating a public key $p{k}_i$ and partial private key $s{k^{\prime }}_i$ for $I{D}_i$. Then $u_i$ generates a complete and valid private key $s{k}_i$ based on $s{k^{\prime }}_i$.

3.

$CT\leftarrow Enc(mpk,S,m)$: The broadcaster injects $mpk$, the set of authorized users $S=\left\{PI{D}_1,PI{D}_2,\dots ,PI{D}_n\right\}$ and the broadcast message $m\in {\left\{0,1\right\}}^l$, generating the corresponding broadcast ciphertext $CT=(Hdr,c_2)$

4.

$(m,K_i)\leftarrow Dec(mpk,s{k}_i,p{k}_i,CT)$: User $u_i$ inputs the broadcast ciphertext $CT$, $mpk$, $s{k}_i$ and $p{k}_i$. If this user is authorized, this decryption algorithm returns the corresponding public encrypted data m and personalized key $K_i$; otherwise, it outputs ⊥.

5.

$ST\leftarrow Trac{e}^D(mpk,S)$: This is a public tracing algorithm. Any tracing entity equipped with the system public key $mpk$ and oracle access to the pirate decoder can execute the tracing procedure and output the set of malicious users involved in constructing the pirate decoder.

6.

$Revok{e}^D\left(mpk\right)$: TA executes the revocation algorithm to disable access for malicious users, and then the broadcaster completes the ciphertext update.

3.4. Security Models

• Game 1. The game involves two participants: the adversary A and the challenger C.
• Initialization Phase. The setup algorithm is executed by C to produce $mpk$ and $msk$, and then sends $mpk$ to A.
• Phase 1. A adaptively sends three types of queries to C. To process these requests, C sustains an initially empty list $L=\left\{(I{D}_i,p{k}_i,s{k}_i)\right\}$.

1.

Public Key Query. The adversary A sends user identity information $I{D}_i$ to initiate a query. If L contains the corresponding $(I{D}_i,p{k}_i,s{k}_i)$, C directly returns $p{k}_i$ to A. If not, C executes the key generation algorithm to get the public–private key pair $(p{k}_i,s{k}_i)$, returns $p{k}_i$ to A, and then adds the record $(I{D}_i,p{k}_i,s{k}_i)$ to L. We assume that for any $I{D}_i$, A must trigger a public key retrieval before initiating any other queries.

2.

Private Key Query. The adversary A sends user identity information $I{D}_i$ to initiate a query. C looks up the corresponding record in L and then returns $s{k}_i$ to A.

3.

Decryption Query. The adversary A sends ciphertext $CT$ and $I{D}_i$ to initiate a query. First, C looks up the corresponding record in L. Then C executes the decryption algorithm to get the decryption result and returns it to A.

• Challenge. When Phase 1 is confirmed to be complete, the adversary A submits a set $S^{*}$ and two equal-length messages $(m_0,m_1)$ to C. In Phase 1, A initiates no private key query for any user in $S^{*}$. Then C randomly chooses $b\in \{0,1\}$ and executes the encryption algorithm to get challenge ciphertext. Finally, C transmits $C{T}^{*}$ to the adversary A.
• Phase 2. Similar to Phase 1, A initiates adaptive queries. A is forbidden to initiate private key queries or decryption queries for any user in $S^{*}$.
• Guess. The adversary A outputs a guess $b^{\prime }$ for b. A wins this game if $b=b^{\prime }$. The advantage of A in winning this security game is defined in Equation (3), where b is the hidden challenge bit chosen by the challenger and $b^{\prime }$ is the adversary’s output guess.

  $$Ad{v}_{BATR}^{IND-CCA}\left(\lambda \right)=\left|Pr[b^{\prime }=b]-{\displaystyle \frac{1}{2}}\right|.$$

  (3)

Definition 2.

If for any PPT adversary A conducting at most $q_{pub}$ public key queries, $q_{pri}$ private key queries, and $q_{dec}$ decryption queries, the advantage of winning this game, then BATR is said to satisfy IND-CCA security.

4. Proposed BATR Construction

4.1. System Setup

Input the security parameter $\lambda$; TA gets a bilinear group $\left(p,G,G_T,e\right)$, randomly selects a generator $g\in G$ and elements $\alpha \in Z_p^{*}$, $h_1,h_2\in G$. TA calculates $g_T=e\left(g,g\right)$ and $g_1=g^{\alpha }$. Then TA selects these hash functions $H_1:{\left\{0,1\right\}}^l\to Z_p^{*}$, $H_2:{\left\{0,1\right\}}^l\times G_T\to Z_p^{*}$, $H_3:G\times G_T\to Z_p^{*}$, $H_4:G_T\to {\left\{0,1\right\}}^w$, $H_5:G_T\to {\left\{0,1\right\}}^l$, $H_6:G\to {\left\{0,1\right\}}^l$ and $H_7:{\left\{0,1\right\}}^l\times G\to G_T$, where w denotes a positive integer. The system public parameter is $mpk=\left\{p,G,G_T,e,g,g_1,g_T,h_1,h_2,{\left\{H_i\right\}}_{i=1}^7,\right\}$ and the master private key is $msk=\alpha$.

4.2. KeyGen

Each user is required to register with TA to obtain their pseudonym and private key. TA is responsible for storing the authentication information on the blockchain. Taking user $u_i$ as an example:

(1)

$u_i$ sends a registration request $I{D}_i$, where $I{D}_i$ represents the real identity information of user $u_i$.

(2)

Upon receiving the registration request, TA first verifies the validity of $I{D}_i$. If the identity verification fails, the request is terminated. Otherwise, $u_i$ randomly selects $c_1,c_2\in Z_p^{*}$, computes $R_1=g^{-c_1}$, $R_2=g^{-c_2}$, $R_3=g_1^{c_1}$, and sends $R_1$ and $R_2$ to TA through a Zero-Knowledge Proof process as shown in Figure 1. If the proof fails, the request is terminated.

(3)

Otherwise, TA computes the pseudonym $PI{D}_i=I{D}_i\oplus H_6\left(TI{D_i}^{\alpha }\right)$ and $\beta =H_1\left(PI{D}_i\right)$, where $TI{D}_i=R_1·R_2$. TA computes the partial private key $s{k_i}^{\prime }=(d_1,d_2)=({(h_1·g^{-c_1})}^{1/(\alpha -\beta )},{(h_2·g^{-c_2})}^{1/(\alpha -\beta )})$, and sets $p{k}_{i1}=R_3={g_1}^{c1}$, $p{k}_{i2}=R_1^{-1}=g^{c_1}$, $p{k}_{i3}=R_2^{-1}=g^{c_2}$, $p{k}_{i4}=p{k}_{i1}·p{k}_{i2}^{-\beta }={(g_1·g^{-\beta })}^{c_1}$, $p{k}_{i5}=e(g,h_1·p{k}_{i2})=e(g,h_1·g^{c_1})$, $p{k}_{i6}=e(g,h_2·p{k}_{i3})=e(g,h_2·g^{c_2})$. TA sends the obtained partial private key $s{k_i}^{\prime }$ and public key $p{k}_i=(p{k}_{i1},p{k}_{i2},p{k}_{i3},p{k}_{i4},p{k}_{i5},p{k}_{i6},PI{D}_i)$ as a response to user $u_i$. Simultaneously, TA invokes saveInfo to upload $u_i$’s authentication information to AIL, which records the legitimate user’s pseudonym $PI{D}_i$, $TI{D}_i$, $p{k}_i$, and the public key expiration time.

(4)

User $u_i$ obtains the corresponding public key $p{k}_i$ and private key $s{k}_i=\left(s{k}_{i1},s{k}_{i2},s{k}_{i3},s{k}_{i4}\right)$$=\left(c_1,c_2,d_1,d_2\right)$.

4.3. Broadcast Encryption

The broadcast inputs $mpk$, the set of authorized users $S=\left\{PI{D}_1,PI{D}_2,\dots ,PI{D}_n\right\}$ where $n\le N$ and the broadcast message $m\in {\left\{0,1\right\}}^l$ to carry out the following content.

(1)

It randomly selects $s\in G$, and the broadcast calculates the session key $K=H_7(m,s)$. It employs a hash function to calculate $r=H_2(M,K)$ required for encryption, and computes $c_{01}=g^r$, $c_{02}=g_1^r$, $c_{03}=g_T^r$ and $c_2=m\oplus H_5\left(K\right)$.

(2)

For each $i\in \left\{1,\dots ,n\right\}$, the broadcast computes ${\varphi }_1=p{k}_{i4}^r$, ${\varphi }_2=c_{03}$ and $\gamma =H_3({\varphi }_1,{\varphi }_2)$. For user $u_i$, the personalized key is $K_i=p{k_{i5}}^{r·\gamma }·p{k}_{i6}^r$.

(3)

Finally, the broadcaster computes $c_{1i}=(c_{1i\_1},c_{1i\_2})=(H_4\left(K_i\right),K·K_i)$. The broadcast ciphertext header is $Hdr=(c_{01},c_{02},c_{03},{\left\{c_{1i}\right\}}_{i=1}^n)$, and the broadcast ciphertext is $CT=(Hdr,c_2)$.

If secure hash functions do not participate in producing the random number r required for encryption, a malicious encryptor could embed a trapdoor in the random number. For example, a malicious encryptor could use $\varpi$ as the random number in all encryption operations. The attacker could use the trapdoor $\varpi$ to compute ${{\varphi }_1}^{\prime }=p{k}_{j4}^{\varpi }$, obtaining $K_j=e{(g,p{k}_{j5})}^{{\gamma }^{\prime }}·p{k}_{j6}^{\varpi }$ and $K=c_{1j\_2}/K_j$ where ${\gamma }^{\prime }=H_3({{\varphi }_1}^{\prime },c_{03})$, and then $m=c_2\oplus H_5\left(K\right)$.

4.4. Broadcast Decryption

User $u_i$ decrypts the broadcast ciphertext $CT=(Hdr,c_2)$ using the private key $s{k}_i$. If $PI{D}_i$ is not in the set of authorized users, the decryption algorithm outputs ⊥. Otherwise, the following steps are executed.

(1)

User $u_i$ computes ${{\varphi }_1}^{\prime }={\left(c_{02}\right)}^{s{k}_{i1}}·{\left(c_{01}\right)}^{-\beta ·s{k}_{i1}}$, ${\gamma }^{\prime }=H_3({{\varphi }_1}^{\prime },{{\varphi }_2}^{\prime })$ and $\beta =H_1\left(PI{D}_i\right)$. Let ${{\varphi }_2}^{\prime }=c_{03}$; the user computes ${K_i}^{\prime }=e{({{\varphi }_1}^{\prime },s{k}_{i3}^{{\gamma }^{\prime }}·s{k}_{i4})}^{1/s{k}_{i1}}·{\left({{\varphi }_2}^{\prime }\right)}^{2({\gamma }^{\prime }·s{k}_{i1}+s{k}_{i2})}$.

(2)

User $u_i$ computes $c_{1i\_1}=H_4\left(K_i\right)$, locates the corresponding $c_{1i}$ in $CT$, then calculates $K^{\prime }=c_{1i\_2}/{K_i}^{\prime }$ and $m^{\prime }=c_2\oplus H_5\left(K^{\prime }\right)$.

(3)

User $u_i$ computes $r^{\prime }=H_2(m^{\prime },K^{\prime })$. If $c_{03}=g_T^{r^{\prime }}$ holds, this algorithm returns the public message m and the personalized key ${K_i}^{\prime }$ for user $u_i$. Otherwise, it outputs ⊥.

4.5. Public Tracing of Data Leakage and Pirate Decoders

We emphasize that BATR handles two different adversarial behaviors. First, trapdoor attacks introduced by malicious encryptors are prevented by construction, because the encryption randomness is generated as $r=H_2(m,K)$, rather than being arbitrarily selected by the encryptor. Hence, the scheme neutralizes malicious encryptor trapdoors at the ciphertext-generation stage. Second, colluding malicious users who leak private keys are identified through the Tardos-code-based public tracing procedure. The maximum number of colluding users that can be reliably identified is determined by the collusion threshold L in the Tardos framework.

The tracing in this scheme can be divided into two cases. The first case is data leakage, where the broadcaster searches for suspicious users through data access records on the blockchain, identifies the pseudonyms $PI{D}_i$ of the suspicious users, and sends them to TA. The second type is private key leakage, where malicious users leak their private keys to attackers, who then construct a pirated decoder with decryption capabilities. The broadcaster assumes the role of the tracer.

(1)

Execute $TC.CodeGen\left(1^{\eta },N\right)$ algorithm to get the code book $\Gamma ={\left\{w_i\right\}}_{i=1}^N$ and $WatMTK=(Z,{\left\{X_i\right\}}_{i=1}^k)$ where k is the code length. Each user $u_i$ where $i\in \left[N\right]$ corresponds to a code word $w_i\in \Gamma$, and the set of authorized users S corresponds to the code word set $\overline{S}=\left\{w_i:i\in I_S\right\}\in \Gamma$. Simultaneously, initialize the pirated code as $w=0^k$.

(2)

For each $j\in 1,2,···,k$, repeat the following steps.

Step 1: Randomly select a broadcast message $m^{*}\in {\left\{0,1\right\}}^l$, execute the encryption algorithm, and generate the corresponding tracing ciphertext $c{\left[j\right]}^{*}\leftarrow Enc(mpk,S,m^{*})$.

Step 2: For each position $j\in \{1,2,\dots ,l\}$, the tracer repeatedly interacts with the pirate decoder on independently generated tracing ciphertexts and estimates the success probability $p_j$ that the decoder outputs the correct decryption result. If the empirical estimate satisfies $p_j\ge {\displaystyle \frac{1}{2}}$, the tracer sets $w\left[j\right]=1$; otherwise, it keeps $w\left[j\right]=0$. We stress that this step is probabilistic rather than deterministic: the pirate code word is reconstructed from repeated sampling, and the final identification guarantee follows from the soundness of the Tardos-code tracing framework.

(3)

The tracer executes $Identify(WatMTK,w)$ algorithm to obtain the result set $\overline{T}(\subseteq \overline{S})$. Finally, the tracing algorithm outputs the set of colluders $ST=\left\{PI{D}_t:w_t\in \overline{T}\right\}(\subseteq S)$, where the users in $ST$ are the malicious users involved in constructing the pirated decoder D.

The tracing procedure in BATR is public: it only relies on the public parameter $mpk$, the codebook, and interactions with the pirate decoder. Hence, the broadcaster or another designated auditor can act as the tracer. By contrast, revocation is not public. Only TA has the privilege to invoke the smart-contract management interfaces and complete the de-anonymization and revocation steps.

4.6. Revocation and De-Anonymization

When users lose connection or their public key expires, TA can call deleteInfo to remove the corresponding authentication tuple from AIL. Furthermore, upon detecting malicious behavior, the tracer submits the information of malicious users, and TA uses deleteInfo to delete the corresponding records from AIL. TA then de-anonymizes the malicious user by computing $I{D}_i=PI{D}_i\oplus H_6\left(TI{D}^{\alpha }\right)$ and holds them accountable. Changes to AIL are propagated to all legitimate users by the blockchain peer nodes, ensuring that legitimate users can promptly delete the corresponding authentication information stored in their ledgers. Simultaneously, the broadcast only needs to remove the malicious user’s corresponding $c_{1i}$ to complete the ciphertext update.

5. Correctness and Security Analysis

5.1. Correctness of Decryption

In this subsection, we prove the correctness of BATR, namely, that any authorized user holding a valid secret key can recover the same personalized key $K_i$ and the same broadcast session key K embedded by the encryptor, and therefore correctly obtain the broadcast message m. The proof shows that the values reconstructed in the decryption phase are algebraically identical to those generated in the encryption phase.

During the decryption phase, the authorized user $u_i$ first reconstructs the intermediate value ${{\varphi }_1}^{\prime }$ according to Equation (4):

$$\begin{array}{cc}\hfill {\varphi }_1^{\prime }& ={\left(c_{02}\right)}^{s{k}_{i1}}·{\left(c_{01}\right)}^{-\beta ·s{k}_{i1}}\hfill \\ \hfill & ={\left(g_1^r\right)}^{c_1}·{\left(g^r\right)}^{-\beta ·c_1}\hfill \\ \hfill & ={(g_1·g^{-\beta })}^{c_1·r}\hfill \\ \hfill & =p{k}_{i4}^r={\varphi }_1\hfill \end{array}$$

(4)

Since ${{\varphi }_2}^{\prime }=c_{03}=g_T^r={\varphi }_2$, it follows that ${\gamma }^{\prime }=H_3({{\varphi }_1}^{\prime },{{\varphi }_2}^{\prime })=\gamma$.

Subsequently, user $u_i$ calculates the personalized session key ${K_i}^{\prime }$ through the algebraic derivation shown in Equation (5):

$$\begin{array}{cc}\hfill K_i^{\prime }& =e{({\varphi }_1^{\prime },s{k}_{i3}^{{\gamma }^{\prime }}·s{k}_{i4})}^{1/s{k}_{i1}}·{\left({\varphi }_2^{\prime }\right)}^{2({\gamma }^{\prime }s{k}_{i1}+s{k}_{i2})}\hfill \\ \hfill & =e{(p{k}_{i4}^r{\left(h_1{g}^{-c_1}\right)}^{\frac{{\gamma }^{\prime }}{\alpha -\beta }}{\left(h_2{g}^{-c_2}\right)}^{\frac{1}{\alpha -\beta }})}^{\frac{1}{c_1}}e{(g,g)}^{2r({\gamma }^{\prime }{c}_1+c_2)}\hfill \\ \hfill & =e{\left({\left(g^{\alpha }{g}^{-\beta }\right)}^{r{c}_1},{\left(h_1{g}^{-c_1}\right)}^{{\gamma }^{\prime }}\left(h_2{g}^{-c_2}\right)\right)}^{\frac{1}{c_1(\alpha -\beta )}}e{(g,g)}^{2r({\gamma }^{\prime }{c}_1+c_2)}\hfill \\ \hfill & =e(g^r,{\left(h_1{g}^{-c_1}\right)}^{{\gamma }^{\prime }}\left(h_2{g}^{-c_2}\right))e{(g,g)}^{2r({\gamma }^{\prime }{c}_1+c_2)}\hfill \\ \hfill & =e{(g,h_1)}^{r{\gamma }^{\prime }}e{(g,g)}^{-r{c}_1{\gamma }^{\prime }}e{(g,h_2)}^{r}e{(g,g)}^{-r{c}_2}e{(g,g)}^{2r({\gamma }^{\prime }{c}_1+c_2)}\hfill \\ \hfill & =e{(g,h_1)}^{r{\gamma }^{\prime }}e{(g,g)}^{r{c}_1{\gamma }^{\prime }}e{(g,h_2)}^{r}e{(g,g)}^{r{c}_2}\hfill \\ \hfill & =e(g,{\left(h_1{g}^{c_1}\right)}^{r{\gamma }^{\prime }})e(g,{\left(h_2{g}^{c_2}\right)}^r)\hfill \\ \hfill & =p{k}_{5i}^{r{\gamma }^{\prime }}p{k}_{6i}^r=K_i\hfill \end{array}$$

(5)

Finally, user $u_i$ computes the session key $K^{\prime }=c_{1i\_2}/{K_i}^{\prime }=(K·{K_i}^{\prime })/{K_i}^{\prime }=K$, and gets the broadcast message $m^{\prime }=c_2\oplus H_5\left(K^{\prime }\right)=(m\oplus H_5\left(K^{\prime }\right))\oplus H_5\left(K^{\prime }\right)=m$.

5.2. IND-CCA Security Under the q-ABDHE Assumption

Theorem 1.

Suppose there exists a PPT adversary A that can break the security of BATR with advantage ε by making at most $q_{pri}$ private key and $q_{dec}$ decryption queries where $q=q_S+q_D+1$. Then a simulator B can solve the Decisional q-ABDHE hard problem with equivalent advantage.

Proof. 

B is given a random instance $(p,G,G_T,e,g,g^{\alpha },g^{{\alpha }^2},...,g^{{\alpha }^q},g^{\prime },{g^{\prime }}^{{\alpha }^{q+2}},T)$ of the Decisional q-ABDHE hard problem. The purpose of B is to determine whether the equation $T=e{(g,g^{\prime })}^{{\alpha }^{q+1}}$ is true. □

Initialization Phase. B executes $Setup\left(\lambda \right)$ algorithm to generate $(p,G,G_T,e,g)$. It randomly selects an element $\alpha \in Z_p^{*}$, and then computes $g_T=e(g,g)$ and $g_1=g^{\alpha }$. The simulator B randomly selects two q-degree polynomials $f_1\left(x\right),f_2\left(x\right)\in Z_p\left[x\right]$, and computes $h_1=g^{f_1\left(x\right)}$ and $h_2=g^{f_2\left(x\right)}$. B employs these hash functions $H_1:{\left\{0,1\right\}}^l\to Z_p^{*}$, $H_2:{\left\{0,1\right\}}^l\times G_T\to Z_p^{*}$, $H_3:G\times G_T\to Z_p^{*}$, $H_4:G_T\to {\left\{0,1\right\}}^w$, $H_5:G_T\to {\left\{0,1\right\}}^l$, $H_6:G\to {\left\{0,1\right\}}^l$ and $H_7:{\left\{0,1\right\}}^l\times G\to G_T$, where w represents a positive integer parameter. The system public parameter is $mpk=\left\{p,G,G_T,e,g,g_1,g_T,h_1,h_2,{\left\{H_i\right\}}_{i=1}^7,l,w\right\}$ and the master private key is $msk=\alpha$. B transmits $mpk$ to A.

Phase 1. A adaptively sends three types of queries to B. To process these requests, B sustains an initially empty list $L=\left\{(I{D}_i,p{k}_i,s{k}_i)\right\}$.

(1)

Public Key Query. A sends user identity information $I{D}_i$ to initiate a query. B defines two $(q-1)$-degree polynomial functions $F_{i1}\left(x\right)=(f_1\left(x\right)-f_1\left(\beta \right))/(x-\beta )$ and $F_{i2}\left(x\right)=(f_2\left(x\right)-f_2\left(\beta \right))/(x-\beta )$. Then B computes the private key $s{k}_i=\left(s{k}_{i1},s{k}_{i2},s{k}_{i3},s{k}_{i4}\right)=(f_1\left(\beta \right),g^{F_{i1}\left(\alpha \right)},f_2\left(\beta \right),g^{F_{i2}\left(\alpha \right)})$ for user $I{D}_i$ based on $(g,g^{\alpha },g^{{\alpha }^2},\dots ,g^{{\alpha }^q})$. Since

$$\begin{array}{cc}\hfill g^{F_{i1}\left(\alpha \right)}& =g^{(f_1\left(\alpha \right)-f_1\left(\beta \right))/(\alpha -\beta )}\hfill \\ \hfill & ={(g^{f_1\left(\alpha \right)}·g^{-f_1\left(\beta \right)})}^{1/(\alpha -\beta )}\hfill \\ \hfill & ={(h_1·g^{-f_1\left(\beta \right)})}^{1/(\alpha -\beta )},\hfill \end{array}$$

$$\begin{array}{cc}\hfill g^{F_{i2}\left(\alpha \right)}& =g^{(f_2\left(\alpha \right)-f_2\left(\beta \right))/(\alpha -\beta )}\hfill \\ \hfill & ={(g^{f_2\left(\alpha \right)}·g^{-f_2\left(\beta \right)})}^{1/(\alpha -\beta )}\hfill \\ \hfill & ={(h_2·g^{-f_2\left(\beta \right)})}^{1/(\alpha -\beta )},\hfill \end{array}$$

$s{k}_i$ is a valid private key for $I{D}_i$. The simulator B computes the public key elements $p{k}_{i1}={g_1}^{f_1\left(\beta \right)}$,$p{k}_{i2}=g^{f_1\left(\beta \right)}$,$p{k}_{i3}=g^{f_2\left(\beta \right)}$,$p{k}_{i4}=p{k}_{i1}·p{k}_{i2}^{-\beta }={(g_1·g^{-\beta })}^{f_1\left(\beta \right)}$,$p{k}_{i5}=e(g,h_1·p{k}_{i2})=e(g,h_1·g^{f_1\left(\beta \right)})$,$p{k}_{i6}=e(g,h_2·p{k}_{i3})=e(g,h_2·g^{f_2\left(\beta \right)})$. The public key is $p{k}_i=(p{k}_{i1},p{k}_{i2},p{k}_{i3},p{k}_{i4},p{k}_{i5},p{k}_{i6},PI{D}_i)$. Finally, B adds $(I{D}_i,p{k}_i,s{k}_i)$ to L and returns $p{k}_i$ to A. For all $I{D}_i$, A must initiate a public key query before initiating the following two types of queries.

(2)

Private Key Query. The adversary A sends $I{D}_i$ to initiate a private key query. B looks up the corresponding record $(I{D}_i,p{k}_i,s{k}_i)$ in L and returns the private key $s{k}_i$ corresponding to $I{D}_i$.

(3)

Decryption Query. A sends ciphertext $CT$ and $I{D}_i$ to initiate a decryption query. Assume the broadcast ciphertext is $CT=(Hdr,c_2)$, where $Hdr=(c_{01},c_{02},c_{03},{\left\{c_{1i}\right\}}_{i=1}^n)$. First, B looks up the corresponding record $(I{D}_i,p{k}_i,s{k}_i)$ in L. Second, B executes the $Dec(mpk,s{k}_i,p{k}_i,CT)$ algorithm, computing ${{\varphi }_1}^{\prime }={\left(c_{02}\right)}^{s{k}_{i1}}·{\left(c_{01}\right)}^{-\beta ·s{k}_{i1}}$, ${\gamma }^{\prime }=H_3({{\varphi }_1}^{\prime },{{\varphi }_2}^{\prime })$ and ${K_i}^{\prime }=e{({{\varphi }_1}^{\prime },s{k}_{i3}^{{\gamma }^{\prime }}·s{k}_{i4})}^{1/s{k}_{i1}}·{\left({{\varphi }_2}^{\prime }\right)}^{2({\gamma }^{\prime }·s{k}_{i1}+s{k}_{i2})}$ where $\beta =H_1\left(PI{D}_i\right)$ and ${{\varphi }_2}^{\prime }=c_{03}$. By computing $c_{1i\_1}=H_4\left(K_i\right)$, B locates the corresponding $c_{1i}$ in $CT$. Then B calculates $K^{\prime }=c_{1i\_2}/{K_i}^{\prime }$ and $m^{\prime }=c_2\oplus H_5\left(K^{\prime }\right)$. Finally, the algorithm computes $r^{\prime }=H_2(m^{\prime },K^{\prime })$. If $c_{03}=g_T^{r^{\prime }}$ holds, it outputs the public message m and the personalized key ${K_i}^{\prime }$ for user $I{D}_i$; if not, it outputs ⊥. Finally, B transmits the result to A.

Challenge. When Phase 1 is confirmed to be complete, A sends a set $S^{*}$ and two equal-length messages $(m_0,m_1)$ to B. In Phase 1, A initiates no private key query for any user in $S^{*}$. B randomly chooses $b\in \{0,1\}$ and computes the challenge ciphertext $C{T}^{*}$ as follows:

Firstly, for all users in $S^{*}$, B specifies the polynomial expression $F_i\left(x\right)=(x^{q+2}-{\beta }_i^{q+2})/(x-{\beta }_i)={\sum }_{t=0}^{q+1}{W}_i^t·x^t$, where $W_i^t$ is the t-th coefficient of the expansion of $F_i\left(x\right)$. Based on $(g,g^{\alpha },g^{{\alpha }^2},\dots ,g^{{\alpha }^q},g^{\prime },{g^{\prime }}^{{\alpha }^{q+2}},T)$, B computes ${\varphi }_1={({g^{\prime }}^{{\alpha }^{q+2}}·{g^{\prime }}^{-{\beta }_i^{q+2}})}^{s{k}_{i1}}$, ${\varphi }_2=T^{W_i^{q+1}}·e({\prod }_{t=0}^q{\left(g^{{\alpha }^t}\right)}^{W_i^t},g^{\prime })$ and ${\gamma }^{\prime }=H_3({\varphi }_1,{\varphi }_2)$. Then, B computes the personalized private key ${K_i}^{\prime }=e{({\varphi }_1,s{k}_{i3}^{{\gamma }^{\prime }}·s{k}_{i4})}^{1/s{k}_{i1}}·{\left({\varphi }_2\right)}^{2({\gamma }^{\prime }·s{k}_{i1}+s{k}_{i2})}$.

Next, B randomly selects an element $s\in G$, computes the session key $K=H_7(m,s)$ and generates the partial ciphertext $c_{1i}^{*}=(c_{1i\_1}^{*},c_{1i\_2}^{*})=(H_4\left(K_i\right),K·K_i)$. Thus B gets $Hd{r}^{*}=(c_0^{*},c_{11}^{*},c_{12}^{*},\dots ,c_{1n}^{*})$ where $c_0^{*}={\varphi }_2$. B randomly chooses $b\in \{0,1\}$ and calculates $C_2^{*}=m_b\oplus H_5\left(K\right)$. The challenge ciphertext is $C{T}^{*}=(Hd{r}^{*},C_2^{*})$.

Finally, B transmits $C{T}^{*}$ to the adversary A.

Phase 2. Similar to Phase 1, A initiates these queries. A is forbidden to initiate private key queries or decryption queries for any users in $S^{*}$.

Guess. A outputs a guess $b^{\prime }$ for b. If $b=b^{\prime }$, then B outputs 1, which means $T=e{(g,g^{\prime })}^{{\alpha }^{q+1}}$. If $b\ne b^{\prime }$, then B outputs 0, which means $T\ne e{(g,g^{\prime })}^{{\alpha }^{q+1}}$.

The advantage of B is analyzed as follows:

-

If $T=e{(g,g^{\prime })}^{{\alpha }^{q+1}}$, then $r_i={log}_g{g}^{\prime }·F_i\left(\alpha \right)$, and the following components defined in Equations (6) and (7) are correctly formed:

$$\begin{array}{cc}\hfill {\varphi }_1& ={\left(g^{\prime {\alpha }^{q+2}}·g^{\prime -{\beta }_i^{q+2}}\right)}^{s{k}_{i1}}\hfill \\ \hfill & =g^{s{k}_{i1}·{log}_g{g}^{\prime }·\left({\alpha }^{q+2}-{\beta }_i^{q+2}\right)}\hfill \\ \hfill & =g^{s{k}_{i1}·r_i\left(\alpha -{\beta }_i\right)}\hfill \\ \hfill & =p{k}_4^{r_i}\hfill \end{array}$$

(6)

$$\begin{array}{cc}\hfill {\varphi }_2& =T^{W_i^{q+1}}·e\left({\displaystyle \prod _{t=0}^q}{\left(g^{{\alpha }^t}\right)}^{W_i^t},g^{\prime }\right)\hfill \\ \hfill & ={\left(e{(g,g^{\prime })}^{{\alpha }^{q+1}}\right)}^{W_i^{q+1}}·e\left({\displaystyle \prod _{t=0}^q}{\left(g^{{\alpha }^t}\right)}^{W_i^t},g^{\prime }\right)\hfill \\ \hfill & =e{(g,g)}^{{log}_g{g}^{\prime }·{\sum }_{t=0}^{q+1}{a}^t·W^t}\hfill \\ \hfill & =g_T^{r_i}\hfill \end{array}$$

(7)

As a result, the challenge ciphertext generated based on Equations (6) and (7) is indistinguishable from a real ciphertext.

When $T=e{(g,g^{\prime })}^{{\alpha }^{q+1}}$, ${\varphi }_1$ and ${\varphi }_2$ are valid values. Therefore, the broadcast ciphertext $C{T}^{*}$ generated based on ${\varphi }_1$ and ${\varphi }_2$ is also valid. At this point, the success probability of A guessing b is $\left|Pr[b=b^{\prime }]-1/2\right|\ge \epsilon$.

-

If $T\ne e{(g,g^{\prime })}^{{\alpha }^{q+1}}$, then T is a random element in $G_T$, so ${\varphi }_1$ and ${\varphi }_2$ are invalid values. Therefore, the broadcast ciphertext $C{T}^{*}$ generated based on ${\varphi }_1$ and ${\varphi }_2$ is also invalid. At this point, the success probability of A guessing b is $Pr[b=b^{\prime }]=1/2$.

Therefore, the advantage of B in solving the Decisional q-ABDHE hard problem is

$$\begin{array}{cc}\hfill & |Pr[B(g,g^{\alpha },g^{{\alpha }^2},\dots ,g^{{\alpha }^q},g^{\prime },{g^{\prime }}^{{\alpha }^{q+2}},e{(g,g^{\prime })}^{{\alpha }^{q+1}})=1]\hfill \\ \hfill & -Pr[B(g,g^{\alpha },g^{{\alpha }^2},\dots ,g^{{\alpha }^q},g^{\prime },{g^{\prime }}^{{\alpha }^{q+2}},T)=1]|\hfill \\ \hfill & \ge \left|(1/2\pm \epsilon )-1/2\right|=\epsilon .\hfill \end{array}$$

6. Performance Evaluation

6.1. Functionality

Table 2. Security functions analysis and comparison.

Schemes	Anonymity	DOSIT	Traceability	Revocation	Resist Trapdoors
[10]	Yes	No	No	Yes	No
[11]	Yes	Yes	No	No	No
[15]	Yes	No	Yes	Yes	No
[16]	Yes	Yes	Yes	Yes	Yes
[18]	Yes	No	Yes	Yes	Yes
BATR	Yes	Yes	Yes	Yes	Yes

presents a comparative analysis of the security attributes between BATR and existing schemes. During the communication process, user $I{D}_i$ employs a pseudonym $PI{D}_i$ for communication, which effectively safeguards user privacy. Only TA can compute the real identity of the user from the pseudonym information. Therefore, this scheme ensures the anonymity of user identities. Secondly, the BATR scheme supports personalized transmission, and this feature not implemented in schemes [10,15,18]. Additionally, the BATR scheme incorporates a dual-tracking method, effectively preventing data leakage and user private key compromise. In contrast, the schemes [10,11] lack tracking capabilities, while the schemes [15,16] do not account for tracking in the event of data leakage. Our scheme achieves the revocation of malicious users. Finally, BATR relies on the property that the output of the hash function is uniformly distributed to resist the malicious encryptor’s embedded trapdoor attack. However, schemes [10,11,15] are not resistant to such attacks. Although the scheme [16] can resist trapdoor attacks by malicious encryptors, the user’s private key in [16] is computed solely by KGC, thus failing to address the key escrow issue.

6.2. Efficiency Analysis

To ensure reproducibility, the operation times reported in

Table 3. Various operations and operation times.

Notations	Description	Time (ms)
H	Hash operation	$13.581$
P	Bilinear operation $G_T$	$11.479$
E	Exponential operation in G/$G_1$	$5.914$
S	Exponential operation in $G_T$	$1.341$

were obtained from a proof-of-concept implementation written in the C programming language by using the native API of the Pairing-Based Cryptography (PBC) library version 0.5.14 [24]. The experiments were conducted on a laptop equipped with an Intel(R) Core(TM) i7-8550U CPU @ 2.00 GHz, 8 GB RAM, and a 64-bit Windows 11 operating system.

The implementation uses a Type-A symmetric pairing in PBC, instantiated over a supersingular elliptic curve of the form $y^2=x^3+x$ defined over a finite field ${\mathbb{F}}_p$. The base-field size is 512 bits and the prime-order subgroup size is 160 bits. Under this parameterization, the element sizes used in the analytical communication/storage comparison are approximately $\left|G\right|=|G_1|=|G_2|=160$ bits and $|G_T|=1024$ bits.

For each primitive operation listed in Table 3, we first executed 100 warm-up runs to reduce the influence of initialization and cache effects. After that, the same operation was executed 1000 times in one batch, and the average runtime per operation in that batch was recorded. This batch measurement procedure was repeated independently 30 times. The final value reported in Table 3 is the arithmetic mean of the 30 batch averages.

The timings in Table 3 are used as primitive-operation baselines. The computational-cost expressions in

Table 4. Comparison of computation cost.

Schemes	Enc	Dec
[10]	$3H+2P+2nE+2S$	$2H+2P+(2n-1)E$
[11]	$P+(n+3)E+3S$	$2P$
[16]	$H+(n+1)P+(n+1)E+(n+3)S$	$3P$
[18]	$P+8nE+nS$	$7nE$
BATR	$(2n+3)H+(n+2)E+(2n+1)S$	$5H+P+3E+2S$

are obtained by counting the dominant cryptographic operations in the corresponding encryption and decryption algorithms and then substituting the average per-operation runtimes from Table 3. The communication and storage expressions in

Table 5. Comparison of communication and storage.

Schemes	Communication CT	Storage mpk	Storage SK
[11]	$2\left|G\right|+(n+1)|G_T|$	$(2n+5)\left|G\right|+|G_T|$	$(n+2)\left|G\right|$
[16]	$3\left|G\right|+(n+1)|G_T|$	$3\sqrt{n}\left|G\right|+|G_T|$	$2\left|G\right|$
[18]	$8n\left|G\right|+(n+1)|G_T|$	$(3n+3)\left|G\right|+n|G_T|$	$(n+4)\left|G\right|$
BATR	$2\left|G\right|+(n+1)|G_T|$	$4\left|G\right|+|G_T|$	$2\left|G\right|$

are derived analytically by counting the number of transmitted or stored group elements and multiplying them by the corresponding element sizes.

6.2.1. Computation Cost

In the performance analysis below, we use $n=\left|S\right|$ to denote the number of authorized users in the broadcast set. This notation is introduced to avoid confusion with the symbol L used earlier in the Tardos-code framework to denote the collusion threshold.

In this paper, the computational-cost expressions in Table 4 are analytically derived by counting the dominant cryptographic operations appearing in the encryption and decryption algorithms of each scheme, including hash evaluations, bilinear pairings, exponentiations in $G/G_1$, and exponentiations in $G_T$. Lightweight operations are disregarded, with focus solely placed on several complex algebraic computations. The execution times for these critical operations are presented in Table 3. Our analysis focuses on computational costs across encryption and decryption phases. Table 4 presents a cost comparison between BATR and other schemes. As illustrated in Figure 4, the encryption costs for both BATR and existing schemes increase with the number of users. However, compared to scheme [18], BATR exhibits a slower rate of increase and lower encryption costs. Nevertheless, since the BATR scheme requires the transmission of personalized data for authorized users, its encryption costs are higher than those of the other three referenced schemes. Meanwhile, the decryption costs for the BATR scheme and schemes [11,16] remain constant, not affected by user quantity. In contrast, the decryption costs for schemes [10,18] increase with the number of users. Therefore, compared to existing schemes, BATR demonstrates superior encryption and decryption algorithms.

Figure 5, Figure 6 and Figure 7 are generated from the analytical expressions in Table 4 and Table 5 under the parameter setting specified in Section 6.2. Therefore, these figures should be interpreted as comparative performance trends rather than raw benchmark measurements.

For BATR, the encryption algorithm performs three constant hash evaluations, namely $H_7(m,s)$, $H_2(m,K)$, and $H_5\left(K\right)$, two exponentiations in G for $c_{01}=g^r$ and $c_{02}=g_1^r$, and one exponentiation in $G_T$ for $c_{03}=g_T^r$. In addition, for each authorized user, encryption requires one exponentiation in G to compute ${\varphi }_1=p{k}_{i4}^r$, one hash evaluation $H_3({\varphi }_1,{\varphi }_2)$, two exponentiations in $G_T$ to compute $p{k}_{i5}^{r\gamma }$ and $p{k}_{i6}^r$, and one hash evaluation $H_4\left(K_i\right)$. Therefore, the total encryption cost is $(2n+3)H+(n+2)E+(2n+1)S$.

For decryption, BATR requires one evaluation of $H_1\left(PI{D}_i\right)$, two exponentiations in G to reconstruct ${\varphi }_1^{\prime }$, one evaluation of $H_3$, one pairing operation, one additional exponentiation in G, two exponentiations in $G_T$, and three further hash evaluations $H_4$, $H_5$, and $H_2$. Hence, the total decryption cost is $5H+P+3E+2S$.

6.2.2. Communication Cost

A comparison of communication costs between existing schemes and the BATR scheme is presented in Table 5. As depicted in Figure 5, the ciphertext size for BATR and existing schemes increases with the number of users. Additionally, the communication overhead of BATR is nearly identical to that of schemes [11,16]. However, compared to scheme [18], BATR exhibits a slower rate of increase in ciphertext size and lower communication costs.

Figure 5, Figure 6 and Figure 7 are plotted from the analytical expressions in Table 4 and Table 5 by substituting the primitive-operation baselines reported in Table 3. Therefore, these figures should be interpreted as analytical comparison trends rather than raw one-shot benchmark measurements.

The communication-cost expressions in Table 5 are also analytically derived. They are obtained by counting the number of transmitted or stored group elements in the ciphertext, public parameters, and private keys, and then multiplying by the corresponding element sizes.

6.2.3. Storage Cost

Table 5 presents a performance comparison between existing schemes and BATR in terms of storage costs. As illustrated in Figure 6, the size of the public parameter in BATR remains constant with a space complexity of $O\left(1\right)$. Conversely, the size of the system public parameter for other schemes grows with the number of users, leading to a significant increase in storage overhead on the user side. Further analysis of Figure 7 reveals that both BATR and scheme [16] achieve optimization in user private key length, with the private key size fixed at two group elements and a space complexity of $O\left(1\right)$. On the other hand, the user private key size in schemes [11,18] grows proportionally to the number of users, resulting in a space complexity of $O\left(n\right)$. BATR’s constant-level storage complexity makes it particularly suitable for resource-constrained lightweight application environments, such as IoT terminal devices or mobile computing platforms.

The communication-cost expressions in Table 5 are obtained by counting the number of group elements appearing in the ciphertext header and message component. For BATR, the ciphertext consists of two elements in G, namely $c_{01}$ and $c_{02}$, together with one element in $G_T$, namely $c_{03}$, and n personalized components $c_{1i}$, each contributing one element in $G_T$. Therefore, the ciphertext communication cost is $2\left|G\right|+(n+1)|G_T|$. The storage expressions are derived in the same way by counting the number of public-parameter and private-key elements stored by the scheme.

7. Conclusions

This paper proposes a blockchain-assisted traceable and revocable broadcast encryption scheme for preventing malicious encryptors (BATR). This scheme leverages uniform distribution property of hash function outputs to resist attacks by malicious encryptors and supports personalized transmission. With the support of blockchain technology, TA and users can dynamically acquire or update identity authentication information stored on the blockchain by invoking APIs, thereby achieving secure authentication. Additionally, in the event of a data breach, malicious users can be accurately identified and located by analyzing data access records stored on the blockchain. If malicious users are found to have leaked their private key, the scheme can effectively trace the malicious users through an interaction between the tracing algorithm and the piracy decoder. Furthermore, the BATR scheme supports the dynamic revocation of access permissions for malicious users, achieved by invoking APIs combined with de-anonymization techniques. Finally, BATR satisfies chosen-ciphertext security. Compared to existing schemes, this scheme exhibits significant performance advantages.