Privacy-Preserving Attribute-Based Keyword Search with Traceability and Revocation for Cloud-Assisted IoT

With the rapid development of cloud computing and Internet of )ings (IoT) technology, it is becoming increasingly popular for source-limited devices to outsource the massive IoT data to the cloud. How to protect data security and user privacy is an important challenge in the cloud-assisted IoT environment. Attribute-based keyword search (ABKS) has been regarded as a promising solution to ensure data confidentiality and fine-grained search control for cloud-assisted IoT. However, due to the fact that multiple users may have the same retrieval permission in ABKS, malicious users may sell their private keys on the Internet without fear of being caught. In addition, most of existing ABKS schemes do not protect the access policy which may contain privacy information. Towards this end, we present a privacy-preserving ABKS that simultaneously supports policy hiding, malicious user traceability, and revocation. Formal security analysis shows that our scheme can not only guarantee the confidentiality of keywords and access policies but also realize the traceability of malicious users. Furthermore, we provide another more efficient construction for public tracing.


Introduction
As a prevalent Internet technology, Internet of ings (IoT) [1] has been widely used in various industries, such as smart healthcare, transportation, and city [2][3][4][5]. Due to the limited computing and storage capacity of many IoT devices, users often need to store IoT data in the cloud. e cloud-assisted IoT [6] technology can be used to collect and store massive medical data, so it is expected to greatly improve the efficiency of medical institutions and promote the development of smart healthcare. Apart from the efficiency concern, security issue is an important concern hindering the widespread application of IoT technology [7][8][9][10]. Especially for the smart healthcare system based on cloud-assisted IoT, the data security issue has become a key challenge, due to the fact that the sensitive personal health record (PHR) outsourced in the cloud is vulnerable to hacker attacks.
Although the traditional encryption technology [11] can protect the data security, it makes the ciphertext data unable to retrieve, thus greatly reducing the availability of IoT data. An inefficient solution is that data users download ciphertext data from the cloud, decrypt it, and then search on plaintext data. However, ordinary users do not have enough storage and computing power to retrieve the huge amount of cloud data locally. Public key encryption with keyword search (PEKS) [12,13] is a more efficient solution, which can realize the retrieval of ciphertext by a cloud server without decryption. In a PEKS scheme, a data user can delegate the cloud server to retrieve all cloud ciphertexts by sending a search token to it. However, in order to avoid the abuse of retrieval ability, data owners usually want to control the retrieval permission.
As an efficient and flexible solution to meet the above requirements, attribute-based keyword search (ABKS) [14,15] can realize data confidentiality, ciphertext retrieval, and fine-grained access control simultaneously. In a ciphertext-policy ABKS (CP-ABKS) system, a data owner encrypts the file keyword by an access policy and only users whose attributes satisfy the access policy can retrieve the ciphertext file. However, the public access policy in CP-ABKS may disclose privacy information in the smart medical cloud system. For example, a medical institution wants to share PHR with users whose attributes meet the policy "(Institution: hospital A AND Patient ID: 202007953) OR (Institution: hospital B AND Position: oncologist)"; then it encrypts the PHR keyword by this policy and generates the corresponding ciphertext. Note that the access policy is exposed together with the ciphertext in the traditional CP-ABKS, so anyone can infer that the patient with the identity "202007953" is likely to have a tumor. Moreover, multiple users with the same attributes have the same retrieval ability and the user identity cannot be determined by the user private key in CP-ABKS, so malicious users may sell their private keys without worrying about being caught. As in the above example, if one of the multiple oncologists in hospital B sells his private key online, it is difficult to accurately identify and revoke the malicious user who sells his private key.

Our Contributions.
Up till now, there is no secure ABKS scheme that simultaneously supports hidden policy, traceability, and revocation. To address these issues, we propose a traceable and revocable hidden ABKS (TR-HABKS) scheme and an enhanced TR-HABKS (eTR-HABKS) scheme, which support the above three properties at once. Moreover, the eTR-HABKS scheme achieves two other remarkable properties: (1) no identity table for tracing: the scheme only needs  to maintain an identity table for revocation but does not  require any identity table for tracing; (2) public traceability: besides the trusted authority, anyone without additional secret information can also run the tracing algorithm to capture malicious users. Specifically, our TR-HABKS and eTR-HABKS schemes provide the following properties: (i) Fine-Grained Search Control. In our schemes, a data user's search token is corresponding to his attributes and can be used to retrieve ciphertext only when the attributes satisfy the ciphertext policy. To control the user search permission, our schemes allow the data owner to encrypt the keyword by a specified access policy, which can be expressed as an ANDgates on multivalued attributes. (ii) Hidden Policy. Our schemes not only guarantee the confidentiality of the keyword but also protect the privacy of the policy. Different from those ABKS schemes which only prove the keyword security, we also prove that access policies are also indistinguishable in the selective security model. Moreover, our schemes require the data owner to encrypt the keyword by his private key, so that the adversary cannot launch the keyword guessing attacks (KGA) by generating the ciphertext himself. (iii) Traceability. Both the TR-HABKS and eTR-HABKS schemes achieve the user traceability in ABKS. When a malicious user leaks his private key in our TR-HABKS scheme, then the trusted authority can determine the identity of the malicious user by a tracing identity table. In our eTR-HABKS scheme, everyone can trace the malicious user's identity without the help of any identity table.
(iv) Revocation . When the malicious user's identity is  determined, our schemes can effectively revoke the  user by managing a registration table. In our  schemes, the trusted authority adds each legitimate  user to a registered identity table in the key generation stage and can easily revoke the malicious  user by deleting his identity from the identity table. e properties comparison between our schemes with other related works can be seen in Table 1. e symbol "-" means not applicable.

Related Work
Attribute-based encryption (ABE) [19] is a practical method for fine-grained access control and can be divided into key-policy ABE (KP-ABE) [20] and ciphertext-policy ABE (CP-ABE) [21,22]. Based on KP-ABE and CP-ABE, dual-policy ABE (DP-ABE) [23,24] was also introduced for achieving content-based and role-based access control simultaneously. However, in traditional CP-ABE and DP-ABE, the access policy corresponding to the ciphertext may disclose the user's privacy. To address this problem, Nishide et al. [25] proposed the first CP-ABE in which access policies can be hidden by the encryptor. Later, Lai et al. [26] presented a high expressive CP-ABE with partially hidden access structure that can be expressed as a linear secret-sharing scheme (LSSS) [27]. Yang et al. [28] proposed a privacy-preserving CP-ABE to hide both the attribute names and the attribute values in the access policy. Based on an optimized vector transformation approach, Sun et al. [29] proposed a lightweight hiding CP-ABE scheme for IoT-oriented smart health. eir scheme can not only support policy hiding but also support offline encryption and outsourcing decryption. In order to prevent key abuse, Hinek et al. [30] first considered the trace problem in ABE and constructed a traceable ABE scheme. Liu et al. [31] proposed a high expressive white-box traceable ABE that supports traceability of the malicious user who sold his decryption key on the Internet. For a decryption blackbox in ABE, Liu et al. [32] later proposed a black-box traceable CP-ABE that can trace the malicious user whose private key was used to construct the decryption device. To support more flexible attributes, Ning et al. [33] presented a traceable CP-ABE that simultaneously supports white-box traceability and large universe. Ying et al. [34] presented a black-box traceable CP-ABE with hidden policy in e-healthcare cloud. Recently, several novel ABE schemes [35][36][37] were proposed for stronger security and user revocation in cloud storage system. Unfortunately, the above ABE schemes cannot search the ciphertext data in the cloud.

Attribute-Based Keyword Search.
Boneh et al. [12] first introduced the concept of PEKS and constructed the first concrete PEKS scheme. In the scheme, the user authorizes a third party to search the ciphertext by giving him a search token that is associated with a keyword; the third party returns the search results to the user but without learning the keyword information. However, Byun et al. [38] pointed out that the PEKS scheme [12] cannot resist KGA. Specifically, anyone can generate a ciphertext by encrypting a keyword in PEKS scheme, so the third party can use the search token to continuously retrieve the ciphertexts corresponding to different keywords to guess the keyword corresponding to the search token. To resist the above attack in PEKS, Huang and Li [16] presented a public key authenticated encryption with keyword search, in which the keyword needs to be authenticated by the data owner during the encryption phase. Miao et al. [39] proposed a verifiable searchable encryption, which can achieve verifiable searchability and resist KGA. In order to support fine-grained search authorization, Zheng et al. [14] proposed a CP-ABKS scheme based on PEKS and CP-ABE [21]. In the CP-ABKS scheme, a data owner encrypts a keyword by an access policy and only users whose attributes meet the access policy can retrieve the ciphertext. With the help of proxy reencryption and lazy reencryption techniques, Sun et al. [15] presented a revocable ABKS scheme that can delegate the search and update workload to the cloud server. Liu et al. [17] proposed a searchable ABE with efficient revocation and outsourced decryption for cloud IoT. Based on online/offline encryption and outsourced decryption techniques, Miao et al. [40] presented an efficient ABKS scheme in the cloud-assisted healthcare IoT system. To protect access policies, Qiu et al. [18] presented a hidden policy CP-ABKS against KGA. Later, Miao et al. [41] presented a privacy-preserving CP-ABKS in multiowner setting. However, Sun et al. [42] pointed out that four types of KGA exist in this scheme. To achieve hidden policy and traceability simultaneously, Liu et al. [43] presented a privacy-preserving ABKS with user tracing. However, the security proof cannot ensure the policy hiding property due to its flawed security model. Unlike with the formal security model in hidden policy CP-ABKS [18,41], the security model in [43] only shows the indistinguishability of keywords and does not consider the indistinguishability of access policies.

Organization.
e rest of this paper is organized as follows. Section 2 introduces the necessary background information of the paper. Section 3 defines the algorithm and model for TR-HABKS. Section 4 presents the TR-HABKS construction and proves its correctness and security. Section 5 presents the eTR-HABKS construction and compares the efficiencies of the TR-HABKS and eTR-HABKS schemes. Section 6 concludes the paper.

Background
For a set S, let s ⟵ R S denote that an element s is chosen uniformly at random from S. Let Z p denote the set 0, 1, 2, . . . , p − 1 , where p is a prime, let [n] denote the set 1, 2, . . . , n { }, where n is a natural number, and let PPT denote probabilistic polynomial time.

Access
Policy. In our system, the total number of attributes is n, and the access policy is represented by an ANDgates on multivalued attributes [25]. For each i ∈ [n], let A i be the attribute index, and let S i � v i,t t∈n i be the possible values of A i , where n i is the number of possible values for A i . Let L � L i be a user attributes set, where L i ∈ S i , and let P � P i i∈ [n] be an access policy, where P i ⊆ S i . If L i ∈ P i for i ∈ [n], we say that the attributes set L satisfies the access policy P, written as L⊨P; otherwise, we say that the attributes set L does not satisfy the access policy P, written as L⊭P. For ease of description, we use i instead of A i to represent attribute index in our schemes.

Bilinear
Map. An asymmetric bilinear group generator G takes as input a security parameter λ and outputs a tuple G � (p, G 1 , G 2 , G T , g 1 , g 2 , e), where p is a prime, G 1 , G 2 , and G T are multiplicative cyclic groups of order p, g 1 (resp., g 2 ) is a generator of G 1 (resp., G 2 ), and e: G 1 × G 2 ⟶ G T is an efficiently computable bilinear map with the following properties: A signature scheme consists of the following algorithms: (PK, SK) ⟵ KeyGen (λ): e key generation algorithm gets the security parameter λ as input. It outputs a random key pair (PK, SK).
e signing algorithm gets a private key SK and a message M as input. It outputs a signature σ.
(0/1) ⟵ Verify (PK, M, σ): e verifying algorithm gets a public key PK, a message M, and a signature σ as input. It outputs 1 if the signature is valid, and outputs 0 otherwise. e existential unforgeability under a weak chosen message attack [44] is defined by the following game:

Problem Formulation
In this section, we describe the algorithm definition, system model, and security model of TR-HABKS.

Algorithm Definition. A TR-HABKS scheme is formally defined as follows:
(MK, PK) ⟵ Setup (λ): the setup algorithm gets the security parameter as input. It outputs the master key MK and the public parameter PK. In addition, it also generates two empty identity tables T 1 and T 2 .
(SK id,L , SK o ) ⟵ KeyGen (MK, PK, id, L): the key generation algorithm gets an attributes set L, an identity id, the master key MK, and the public parameter PK as input. It outputs a private key SK id,L for a data user and a private key SK o for the data owner. In addition, it adds id to T 1 and T 2 . CT ⟵ Enc (ω, P, SK o , PK): the encryption algorithm gets a keyword ω, an access policy P, the data owner's private key SK o , and the public parameter PK as input. It outputs a ciphertext CT. TK id,L ⟵ TokenGen (SK id,L , PK, ω ′ ): the token generation algorithm gets a data user's private key SK id,L , the public parameter PK, and a keyword ω ′ as input. It outputs a search token TK id,L . (0/1) ⟵ Search (TK id,L , CT, T 1 ): the searching algorithm gets a ciphertext CT, a search token TK id,L , and an identity table T 1 as input. It outputs 1 if (1) L⊨P, (2) id ∈ T 1 , and (3) ω � ω ′ and outputs 0 otherwise. (id/⊤) ⟵ Trace (SK id,L , PK, T 2 ): the tracing algorithm gets a secret key SK id,L , the public parameter PK, and an identity table T 2 as input. It outputs a user identity id if SK id,L passes the key sanity check and outputs symbol ⊤ otherwise. Key sanity check is a deterministic algorithm to test whether SK id,L needs to be traced.
: the revocation algorithm gets a revocation user identity id and an identity table T 1 as input. It outputs an updated table T 1 . Figure 1, our TR-HABKS system includes four entities: a trusted authority (TA), a data owner (DO), a cloud sever (CS), and multiple data users (DUs). Specifically, the role of each entity in our system model is described below.

System Model. As depicted in
TA: TA first runs the setup algorithm, keeps the master key MK secretly, and publishes the public parameter PK. en, he uses his master key to generate private keys for DO and DUs. In addition, he creates an identity table T 1 for user revocation and another identity table T 2 for the malicious user tracing. When a malicious user sells his private key on the Internet, TA runs the tracing algorithm and then obtains the malicious user identity id from T 2 . Finally, TA deletes id from table T 1 and sends T 1 to CS to revoke the malicious user's search ability. DO: when DO wants to encrypt a keyword ω under an access policy P, he runs the encryption algorithm with his private key SK o and then generates a ciphertext CT corresponding to (P, ω). Finally, he outsources the corresponding ciphertext CT to the cloud. DU: when DU wants to search the data files with the keyword ω ′ , he runs the token generation algorithm with his private key SK id,L and then generates a search token TK id,L corresponding to (id, L, ω ′ ). Finally, he sends TK id,L to CS to query documents containing the keyword ω ′ . CS: when CS receives the search token TK id,L from DU, he first searches id in the table T 1 . If id ∉ T 1 , CS returns 0 and aborts; otherwise, CS runs the searching algorithm and returns the search result to DU. In our threat model, TA and DO are assumed to be fully trusted; that is, they execute the above algorithm honestly and will not attack the system. CS is assumed to be an honest-but-curious adversary who honestly executes the searching algorithm but tries to infer the privacy of keywords. Note that the generation of ciphertext needs to use the private key of DO, so CS cannot generate ciphertext by itself and carry out keyword guessing attack. DUs in our system may be malicious adversaries who not only try to retrieve the ciphertext beyond their retrieval permission but also leak their private keys to others.

Security Model.
In order to realize the confidentiality of keywords and access policies simultaneously, the security model of our TR-HABKS scheme requires that the adversary cannot distinguish between the encryption of a keyword ω 0 under an access policy P 0 and the encryption of a keyword ω 1 under an access policy P 1 . In the selective security model, the adversary needs to submit two challenge access policies P 0 and P 1 before the Setup phase. e selective security game includes the following phases: Inti: the adversary declares two challenge access policies P 0 and P 1 that he tries to attack and gives them to the challenger. Setup: the challenger calls the setup algorithm (MK, PK) ⟵ Setup (λ) and gives the public parameter PK to the adversary. Query Phase1: the adversary can repeatedly ask for private keys and search tokens as follows: Challenge: the adversary submits two keywords ω 0 and ω 1 that satisfy the following constraint. If the adversary has queried the private key or search token for the attributes set L that satisfies both access policies P 0 and P 1 , then we require that ω 0 � ω 1 . e challenger flips a random coin c ∈ 0, 1 { } and returns the challenge ciphertext CT * ⟵ Enc (ω c , P c , SK o , PK) to the adversary. Query Phase2: phase 1 is repeated with the restriction that the adversary cannot query the private key or search token for the attributes set L when (L⊨P 0 ∧L⊨P 1 ) and ω 0 ≠ ω 1 . Guess: the adversary outputs a guess c ′ ∈ 0, 1 { }.
e adversary wins this game if c � c ′ , and his advantage is defined as Pr[c � c ′ ] − (1/2).

Definition 2.
A TR-HABKS scheme is said to be selectively secure if all PPT adversaries have only a negligible advantage in the above security game. e traceability game of TR-HABKS is described as follows: Setup: the challenger runs the setup algorithm (MK, PK) ⟵ Setup (λ) and gives the public parameter PK to the adversary. Key query: the adversary queries the private keys corresponding to pairs (id j , L j ) j∈[q s ] , where id j is an identity, L j is an attributes set, and q s is the maximum number of private keys that the adversary can query. e challenger returns the corresponding user private keys SK id j ,L j j∈[q s ] .
Key forgery: the adversary outputs a user private key SK * .

Our TR-HABKS Scheme
In this section, we propose the construction of our TR-HABKS scheme and prove that it is selectively secure and fully traceable in the generic bilinear group model. We first adopt the technique from [18,25] to realize hidden policy. e access policy P is embedded in the ciphertext CT as ,2 ; otherwise, we set C i,t,1 and C i,t,2 as two random elements in G 1 .
at is, if v i,t ∈ P i , these ciphertext components C i,t,1 , C i,t,2 are well formed and can be used for successful search; otherwise, the ciphertext components C i,t,1 , C i,t,2 are malformed. As it is hard to distinguish the well-formed ciphertext components from the malformed ciphertext components, the user cannot get the access policy from the corresponding ciphertext. en, we exploit the signature technique in [31,44] to realize the user traceability. On one hand, we inject the message y id and its signature into the user private key; then DU cannot rerandomize the private key component y id . On the other hand, we add the message y id and the corresponding user identity id in the identity table T 2 ; then TA can identify the malicious user by the private key and the table T 2 . Finally, we add the legitimate user to the system by storing the user identity id and its corresponding element C id in the registered identity table T 1 and revoke the malicious user by deleting the corresponding pair (id, C id ) from the table T 1 . (λ): TA first runs G(λ) to obtain (p, G 1 , G 2 , G T , g 1 , g 2 , e), where G 1 , G 2 , and G T are cyclic groups with prime order p, and e: G 1 × G 2 ⟶ G T is a bilinear map. en, TA picks a, b, c ⟵ R Z p and a one-way hash function H: 0, 1 { } * ⟶ Z p . For each i ∈ [n], TA chooses random exponents a i,t ∈ Z p t∈[n i ] and computes

Construction. Setup
Next, TA sets MK � (a, b, c, a i,t t ∈ [n i ] i∈ [n] ) as his master key and publishes the public parameter PK � (p, G 1 , G 2 , G T , g 1 , g 2 , e, e(g 1 , g 2 ) a , g b 1 , g c 1 , g bc ). Finally, TA creates two empty identity tables T 1 and T 2 . KeyGen (MK, PK, id, L): DU submits his identity id and attributes set L � v i,t i i∈ [n] to TA in order to apply for the user private key. TA first picks x id , y id , β ⟵ R Z p and sets en, TA sets SK id,L � (K, K 0 , K 1 , K i,1 , K i,2 i∈[n] ) as DU private key and sends it to the DU with identity id. Next, TA picks α ⟵ R Z p , sets SK o � α as DO private key, and sends it to DO. After that, TA computes C id � e(g 1 , g 2 ) − aαx id , stores (id, C id ) in the registered identity table T 1 , and sends T 1 to CS for search permission revocation. Finally, TA adds (id, y id ) in the identity table T 2 and secretly stores T 2 for user tracing.
Search (TK id,L , CT, T 1 ): when CS receives the search token TK id,L � (tok 0 , tok, tok 1 , T i,1 , T i,2 i∈[n] ) from the DU with identity id, it first searches the entry (id, C id ) in the table T 1 . If no such entry exists, CS returns 0 and aborts; otherwise, CS obtains C id from T 1 and runs the following search algo- ) � e(g 1 , g 2 ) αβs(y id +c) . Finally, CS returns 1 if EC tok C id � e(C tok 1 0 C 1 , tok 0 ) and 0 otherwise.
If the private key SK id,L does not pass the above check, TA returns ⊤ and aborts; otherwise, TA searches the entry (id, K 1 ) in table T 2 and returns the corresponding id.
Revoke (id, T 1 ): to revoke the search permission of the malicious user with identity id, TA updates table T 1 by deleting the entry (id, C id ) and sends new table T 1 to CS.

Correctness Proof.
We now prove the correctness of our TR-HABKS scheme. If Scheme. If the user attributes L � v i,t i i∈[n] satisfy the access policy P � P i i∈[n] , we have v i,t i ∈ P i and C i, (2) If the user id is in table T 1 , then CS can obtain the corresponding C id � e(g 1 , g 2 ) − aαx id . erefore, (3) In this case, if ω � ω ′ , we have e C (4)

Proof of Selective Security.
In this part, we prove the confidentiality of keywords and access policies in our scheme by a security reduction to the QLSZ scheme [18]. More specifically, if there are any attacks in our TR-HABKS scheme, then we can use these attacks to break the QLSZ scheme in the generic bilinear group model [18,45]. Followed by the definition in [45], we consider three random encodings φ 1 , φ 2 , φ T : F p ⟶ 0, 1 { } m , where F p is an additive group and m > 3 log(p) . For i � 1, 2 x ∈ F p . erefore, there are three oracles to compute the group action on G 1 , G 2 , G T and an oracle to compute the bilinear map e. We refer to G 1 as a generic bilinear group. In addition, our TR-HABKS scheme only allows DO to generate ciphertext by his private key, so the adversary cannot successfully carry out the keyword guessing attack.

Theorem 1. If the QLSZ scheme is selectively secure in the generic bilinear group model, then our TR-HABKS scheme is selectively secure.
Proof. Suppose that there exists a PPT adversary A that can break our TR-HABKS scheme with advantage ε in the selective security model. We will build a simulator B that can break the QLSZ scheme with advantage ε. Let C be the challenger corresponding to B in the security game of QLSZ scheme. For more information about the QLSZ scheme and its security, please refer to [18].
Inti: simulator B receives two challenge access policies P 0 and P 1 from adversary A and then sends these policies to challenger C. Setup: C sends the QLSZ public parameter PK � (p, G 1 , G 2 , G T , g 1 , g 2 , e, e(g 1 , g 2 ) a , g b 1 , H, A i,t t ∈ [n i ] i∈ [n] ) to B. en, B picks c ⟵ R Z p , sets , and sends the public parameter PK � (p, G 1 , G 2 , G T , g 1 , g 2 , e, e(g 1 , g 2 ) a , ) to A.

Security and Communication Networks
Query Phase1: B answers the adversary's private key and search token queries in our TR-HABKS scheme as follows: (1) Private key query O KeyGen (id, L): in order to create the user private key for a pair (id, L) requested by A, B first sends (id, L) to C to query the corresponding user private key in QLSZ scheme. When B receives the QLSZ private key SK � (x id , K 0 ′ � ), it picks Finally, B sets the user private key SK id,L � (K, K 0 , K 1 , K i,1 , K i,2 i∈ [n] ) and sends it to A.
Finally, B sets the search token TK id,L � (tok 0 , tok, tok 1 , T i,1 , T i,2 i∈ [n] ) and sends it to A.
Challenge: A submits two keywords ω 0 and ω 1 to B, where the pair (ω 0 , ω 1 ) satisfies the following constraint. If the adversary has queried the private key or search token for the attributes set L that satisfies both access policies P 0 and P 1 , then we require that ω 0 � ω 1 . Next, B sends ω 0 and ω 1 to C to obtain the QLSZ challenge ciphertext CT ′ � (C ′ , C 0 ′ , C i,1 ′ , 1 and returns the challenge ciphertext CT * � (C, C 0 , C 1 , ) to A. Query Phase2: same as Phase 1. Guess: finally, A outputs a guess c ′ ∈ 0, 1 { }, and then B sends c ′ to C.
According to the above simulation, if A has advantage ε in the selective security game against our scheme, then B can use A to break the QLSZ scheme with the same advantage ε. □ 4.4. Proof of Traceability. In this part, we prove that our TR-HABKS scheme is fully traceable based on the BB basic signature scheme, which has been proved to be existentially unforgeable under a weak chosen message attack in [44]. In order to prove the traceability, we assume that there exists a PPT adversary A who can win the traceability game, and then we construct a simulator B that can break the BB basic signature scheme under a weak chosen message attack. Let C denote the BB challenger corresponding to B in the signature security game. For more information about the BB basic signature scheme and its security, please refer to [44].

Theorem 2.
If the BB basic signature scheme is existentially unforgeable under a weak chosen message attack, then our TR-HABKS scheme is fully traceable.
Proof. Before the game starts, challenger C sets a bilinear group (p, G 1 , G 2 , G T , g 1 , g 2 , e). G 1 , G 2 , and G T are the cyclic groups of prime order p, g 1 is a generator of G 1 , g 2 is a generator of G 2 , and e: G 1 × G 2 ⟶ G T is a bilinear map. and makes signature queries by submitting the values y j ∈ Z p j∈[q s ] to challenger C. en, C sends the BB public parameter PK � (p, G 1 , G 2 , G T , e, g 1 , g 2 , g c 1 ) and the corresponding signatures y j ,

For each i ∈ [n], B chooses random exponents a i,t ∈ Z p t∈[n i ] and computes
Next, B picks a, b ⟵ R Z p and a one-way hash function H: 0, 1 { } * ⟶ Z p and computes e(g 1 , g 2 ) a , g b 1 , g c 1 , g bc 1 . Finally, B sends the public parameter PK � (p, G 1 , G 2 , G T , g 1 , g 2 , e, e(g 1 , g 2 ) a , g b 1 , g c 1 , g bc 1 , H, A i,t,1 , A i,t,2 t ∈ [n i ] i∈ [n] ) to adversary A and initializes an empty identity table T 2 .

Key query.
When A makes user private key query for (id j , L j ), B first picks x j , β ⟵ R Z p and sets K j � x j , as the corresponding private key and returns it to A. Finally, B adds (id j , y j ) to T 2 .

Key forgery. Adversary
A outputs a user private key SK * .
If A wins the above traceability game, then Trace(SK * , PK, T 2 ) ∉ id 1 , id 2 , . . . , id q s , ⊤ . Hence, the key SK * � (K, K 0 , K 1 , K i,1 , K i,2 , K i,3 i∈[n] ) satisfies the following conditions: K 1 ∉ y 1 , y 2 , . . . , y q s , K, K 1 ∈ Z p , K 0 , K i,1 , and ∃i ∈ [n], s.t. e(g bc where β i ∈ Z p and λ i ∈ Z p are unknown, we have e(g b(K 1 +c) 1 , and then e(g 8 Security and Communication Networks ) � e(g 1 , g and then obtains a valid signature σ on message K 1 , where K 1 ∉ y 1 , y 2 , . . . , y q s . Hence, if A has advantage ε in the traceability game, then B can forge a valid BB basic signature scheme with advantage ε under a weak chosen message attack.

Our eTR-HABKS System
In this section, we describe our enhanced TR-HABKS system based on our TR-HABKS scheme in Section 4. Different from the TR-HABKS scheme, the tracing algorithm in this system is public traceable and does not require any identity table. In addition, the efficiency comparison shows that the storage overhead of the eTR-HABKS system is much smaller than that of the TR-HABKS scheme. ) as his master key and publishes the public parameter PK � (p, G 1 , G 2 , G T , g 1 , g 2 , e, e(g 1 , g 2 ) a , g b 1 , g c 1 , g d 1 , g bc

Concrete
). Finally, TA creates an empty identity table T 1 .

User Registration.
In this phase, TA uses his master key to generate the private keys for the registered DUs and DO. When DU wants to join the system, he submits his identity id ∈ Z p and attributes set L � v i,t i i∈ [n] to TA to apply for his private key. TA first picks x id , r, β ⟵ R Z p and 3 i∈[n] ) as the user private key and sends it to the corresponding DU. en, TA picks α ⟵ R Z p and sets SK o � α as the data owner private key and sends it to DO. Finally, TA computes C id � e(g 1 , g 2 ) − aαx id , stores (id, C id ) in the identity table T 1 , and sends T 1 to CS.

Secure Index Generation.
In this phase, DO uses his private key to generate a secure index for each file and outsources all the files and indexes in the cloud.
When DO wants to share a file with the specific data users, he extracts a keyword ω ∈ 0, 1 { } * from the file and encrypts the keyword ω under an access policy P � P i i∈ [n] . DO first computes C � e(g 1 , g 2 ) aα , C 0 � g bα/H(ω) 2 as a random element in G 1 . Finally, DO stores the encrypted [n] in the cloud.

Search Token Generation.
In this phase, DU generates a search token for a keyword ω ′ ∈ 0, 1 { } * , and sends the search token to CS for the data retrieval request. 3 . Finally, DU sets the search token TK id,L � (tok 0 , tok, tok 1 , tok 2 , T i,1 , T i,2 , T i,3 i∈[n] ).

Data
Retrieval. In this phase, CS uses the token to search the data in the cloud and responds the search results to DU.
When CS receives the retrieval request and the search token TK id,L � (tok 0 , tok, tok 1 , tok 2 , T i,1 , T i,2 , T i,3 i∈[n] ) from DU, it first searches the entry (id, C id ) in T 1 . If no such entry exists, CS returns error symbol ⊥ and aborts; otherwise, CS obtains C id from T 1 and then runs the following search algorithm. If Algorithm.

User
Tracing. In this phase, TA traces the malicious user who sales his private key SK id,L on the Internet and outputs the malicious user's identity.
TA first checks whether SK id,L is a well-formed key. If the private key is not in the form of SK id,L � (K, K 0 , If SK id,L does not pass the above check, it returns ⊤ and aborts; otherwise, it returns K 1 as the corresponding user identity.

User Revocation.
In this phase, TA revokes the search permissions of the malicious users. When TA obtains the malicious user identity id, he updates table T 1 by deleting the entry (id, C id ) and sends the new table T 1 to CS.

Correctness Proof.
e correctness of our TR-HABKS scheme is proved as follows. If the user attributes L � v i,t i i∈ [n] satisfy the access policy P � P i i∈ [n] , we have v i,t i ∈ P i and C i, If the user id is in the table T 1 , then CS has the corresponding C id � e(g 1 , g 2 ) − aαx id . erefore, EC tok C id � e g 1 , g 2 αβs(id+c+dr) e g 1 , g 2 aα x id +s ( ) e g 1 , g 2 − aαx id � e g 1 , g 2 αβs(id+c+dr) e g 1 , g 2 aαs .
In this case, if ω � ω ′ , we have e security proofs of our eTR-HABKS scheme are almost the same as that in Section 4, so we omit the details here. Table 2 compares the storage costs of our schemes with that of QLSZ scheme [18]. e length of the public parameter/ciphertext of all three schemes increases linearly with i∈[n] n i , where n is the total number of attributes in the system and n i is the number of possible values for attribute index i. Compared with QLSZ scheme, the public key and ciphertext size of our TR-HABKS scheme have almost doubled, but the public key and ciphertext size of our eTR-HABKS scheme are only increased by 4 and 2 + n elements, respectively. e user private key/token size of all schemes grows linearly with the total number of attributes, and the user private key/token of the eTR-HABKS scheme is about 1.5 times as long as that of other schemes. Note that n is far less than i∈[n] n i , so the system storage overhead of the eTR-HABKS scheme is much less than that of the TR-HABKS scheme, although the user storage overhead of the eTR-HABKS scheme is slightly greater. In addition, the eTR-HABKS scheme only needs to maintain an identity table T 1 for revocation but does not require any identity table for tracing, which makes our eTR-HABKS scheme more practical. Figure 2 illustrates the system storage overhead for tracing (including the public parameter and the storage for tracing) in our TR-HABKS and eTR-HABKS schemes. We set the group element size to 160 bits and the random number and identity size to 1024 bits, and i∈[n] n i � 100. From Figure 2, it is easy to see that the system storage overhead for tracing in our eTR-HABKS scheme is constant and significantly smaller than that grows linearly with the number of users in TR-HABKS scheme. Table 3 gives a computation cost comparison that ignores nondominant operations in the schemes. E 1 , E 2 , and E T denote an exponentiation operation in groups G 1 , G 2 , and G T , respectively. P is a bilinear pairing operation and |P i | (|P i | ≤ n i ) is the number of attribute values in P i . Let "Trace (max)" and "Trace (min)" denote the maximum and minimum computation cost for successful tracing, respectively. From Table 3, we can see that the computation cost in the setup and encryption algorithms of the eTR-HABKS scheme is almost the same as that of QLSZ scheme, but it is obviously smaller than that of the TR-HABKS scheme. All three schemes have the same level of computation overhead in key generation and token generation algorithms. Compared with QLSZ scheme, our TR-HABKS and eTR-HABKS schemes do not add any computation overhead to achieve user revocation but add more computation overhead to realize user accountability. However, the increased computation burden has little effect on the performance of our eTR-HABKS system, because the search and tracing algorithms can be executed by the cloud with powerful computing capability.

Conclusion
In this paper, we first presented a new privacy-preserving ABKS construction for cloud-assisted IoT and then proved that it is selectively secure and fully traceable in the generic bilinear group model. We also proposed another ABKS construction with public traceability and showed that it is more efficient than the first construction. In short, our two constructions not only reduce privacy leakage by hiding access policies but also prevent private key abuse by tracing and revoking malicious users. As our schemes are designed for just one-owner setting, we aim to construct a traceable and revocable ABKS scheme with policy protection in multiowner setting in the future.

Data Availability
No data were used to support the findings of this study.