Security and Privacy Challenges in Internet of Things and Mobile Edge ComputingView this Special Issue
Privacy-Preserving Attribute-Based Keyword Search with Traceability and Revocation for Cloud-Assisted IoT
With the rapid development of cloud computing and Internet of Things (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.
As a prevalent Internet technology, Internet of Things (IoT)  has been widely used in various industries, such as smart healthcare, transportation, and city [2–5]. Due to the limited computing and storage capacity of many IoT devices, users often need to store IoT data in the cloud. The cloud-assisted IoT  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–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  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.
1.1. 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 AND-gates 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.
The properties comparison between our schemes with other related works can be seen in Table 1. The symbol “—” means not applicable.
1.2. Related Work
1.2.1. Attributed-Based Encryption
Attribute-based encryption (ABE)  is a practical method for fine-grained access control and can be divided into key-policy ABE (KP-ABE)  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.  proposed the first CP-ABE in which access policies can be hidden by the encryptor. Later, Lai et al.  presented a high expressive CP-ABE with partially hidden access structure that can be expressed as a linear secret-sharing scheme (LSSS) . Yang et al.  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.  proposed a lightweight hiding CP-ABE scheme for IoT-oriented smart health. Their scheme can not only support policy hiding but also support offline encryption and outsourcing decryption. In order to prevent key abuse, Hinek et al.  first considered the trace problem in ABE and constructed a traceable ABE scheme. Liu et al.  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 black-box in ABE, Liu et al.  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.  presented a traceable CP-ABE that simultaneously supports white-box traceability and large universe. Ying et al.  presented a black-box traceable CP-ABE with hidden policy in e-healthcare cloud. Recently, several novel ABE schemes [35–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.
1.2.2. Attribute-Based Keyword Search
Boneh et al.  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.  pointed out that the PEKS scheme  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  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.  proposed a verifiable searchable encryption, which can achieve verifiable searchability and resist KGA. In order to support fine-grained search authorization, Zheng et al.  proposed a CP-ABKS scheme based on PEKS and CP-ABE . 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.  presented a revocable ABKS scheme that can delegate the search and update workload to the cloud server. Liu et al.  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.  presented an efficient ABKS scheme in the cloud-assisted healthcare IoT system. To protect access policies, Qiu et al.  presented a hidden policy CP-ABKS against KGA. Later, Miao et al.  presented a privacy-preserving CP-ABKS in multiowner setting. However, Sun et al.  pointed out that four types of KGA exist in this scheme. To achieve hidden policy and traceability simultaneously, Liu et al.  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  only shows the indistinguishability of keywords and does not consider the indistinguishability of access policies.
The 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.
For a set , let denote that an element is chosen uniformly at random from . Let denote the set , where is a prime, let denote the set , where is a natural number, and let PPT denote probabilistic polynomial time.
2.1. Access Policy
In our system, the total number of attributes is , and the access policy is represented by an AND-gates on multivalued attributes . For each , let be the attribute index, and let be the possible values of , where is the number of possible values for . Let be a user attributes set, where , and let be an access policy, where . If for , we say that the attributes set satisfies the access policy , written as ; otherwise, we say that the attributes set does not satisfy the access policy , written as . For ease of description, we use instead of to represent attribute index in our schemes.
2.2. Bilinear Map
An asymmetric bilinear group generator takes as input a security parameter and outputs a tuple , where is a prime, , and are multiplicative cyclic groups of order , (resp., ) is a generator of (resp., ), and is an efficiently computable bilinear map with the following properties:(1)Bilinear: (2)Nondegenerate:
A signature scheme consists of the following algorithms: KeyGen : The key generation algorithm gets the security parameter as input. It outputs a random key pair . Sign : The signing algorithm gets a private key and a message as input. It outputs a signature . Verify : The verifying algorithm gets a public key , a message , and a signature as input. It outputs 1 if the signature is valid, and outputs 0 otherwise.
The existential unforgeability under a weak chosen message attack  is defined by the following game: Query: the adversary sends messages to the challenger, where is the maximum number of signatures that the adversary can query. Response: the challenger runs the key generation algorithm and generates the signatures on the messages . Then, the challenger gives the public key and the signatures to the adversary. Output: the adversary outputs a pair .
The adversary wins this game if verify and . The adversary’s advantage is defined as the probability that he wins this game.
Definition 1. A signature scheme is said to be existentially unforgeable under a weak chosen message attack if all PPT adversaries have only a negligible advantage in this game.
3. Problem Formulation
In this section, we describe the algorithm definition, system model, and security model of TR-HABKS.
3.1. Algorithm Definition
A TR-HABKS scheme is formally defined as follows: Setup : the setup algorithm gets the security parameter as input. It outputs the master key and the public parameter . In addition, it also generates two empty identity tables and . KeyGen : the key generation algorithm gets an attributes set , an identity , the master key , and the public parameter as input. It outputs a private key for a data user and a private key for the data owner. In addition, it adds to and . Enc : the encryption algorithm gets a keyword , an access policy , the data owner’s private key , and the public parameter as input. It outputs a ciphertext . TokenGen : the token generation algorithm gets a data user’s private key , the public parameter , and a keyword as input. It outputs a search token . Search : the searching algorithm gets a ciphertext , a search token , and an identity table as input. It outputs 1 if , , and and outputs 0 otherwise. Trace : the tracing algorithm gets a secret key , the public parameter , and an identity table as input. It outputs a user identity if passes the key sanity check and outputs symbol otherwise. Key sanity check is a deterministic algorithm to test whether needs to be traced. Revoke : the revocation algorithm gets a revocation user identity and an identity table as input. It outputs an updated table .
A TR-HABKS scheme is correct if the following condition holds: Given Setup KeyGen Enc , TokenGen , where and ; then Search outputs 1 when .
3.2. System Model
As depicted in 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. TA: TA first runs the setup algorithm, keeps the master key secretly, and publishes the public parameter . Then, he uses his master key to generate private keys for DO and DUs. In addition, he creates an identity table for user revocation and another identity table 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 from . Finally, TA deletes from table and sends to CS to revoke the malicious user’s search ability. DO: when DO wants to encrypt a keyword under an access policy , he runs the encryption algorithm with his private key and then generates a ciphertext corresponding to . Finally, he outsources the corresponding ciphertext 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 and then generates a search token corresponding to . Finally, he sends to CS to query documents containing the keyword . CS: when CS receives the search token from DU, he first searches in the table . If , 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.
3.3. 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 under an access policy and the encryption of a keyword under an access policy . In the selective security model, the adversary needs to submit two challenge access policies and before the Setup phase. The selective security game includes the following phases: Inti: the adversary declares two challenge access policies and that he tries to attack and gives them to the challenger. Setup: the challenger calls the setup algorithm Setup and gives the public parameter to the adversary. Query Phase1: the adversary can repeatedly ask for private keys and search tokens as follows:(1)Private Key Query: the adversary submits an identity and an attributes set to the challenger. If or , then abort; otherwise, the challenger returns the corresponding private key .(2)Search Token Query: the adversary submits an identity , an attributes set , and a keyword to the challenger. The challenger returns the corresponding search token . Challenge: the adversary submits two keywords and that satisfy the following constraint. If the adversary has queried the private key or search token for the attributes set that satisfies both access policies and , then we require that . The challenger flips a random coin and returns the challenge ciphertext Enc 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 when and . Guess: the adversary outputs a guess .
The adversary wins this game if , and his advantage is defined as .
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.
The traceability game of TR-HABKS is described as follows: Setup: the challenger runs the setup algorithm Setup and gives the public parameter to the adversary. Key query: the adversary queries the private keys corresponding to pairs , where is an identity, is an attributes set, and is the maximum number of private keys that the adversary can query. The challenger returns the corresponding user private keys . Key forgery: the adversary outputs a user private key .In this game, the adversary’s advantage is defined as .
Definition 3. A TR-HABKS scheme is said to be fully traceable if all PPT adversaries have only a negligible advantage in this traceability game.
4. 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. The access policy is embedded in the ciphertext as follows: if , we set ; otherwise, we set and as two random elements in . That is, if , these ciphertext components are well formed and can be used for successful search; otherwise, the ciphertext components 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. Then, we exploit the signature technique in [31, 44] to realize the user traceability. On one hand, we inject the message and its signature into the user private key; then DU cannot rerandomize the private key component . On the other hand, we add the message and the corresponding user identity in the identity table ; then TA can identify the malicious user by the private key and the table . Finally, we add the legitimate user to the system by storing the user identity and its corresponding element in the registered identity table and revoke the malicious user by deleting the corresponding pair from the table .
Setup : TA first runs to obtain , where , and are cyclic groups with prime order , and is a bilinear map. Then, TA picks and a one-way hash function . For each , TA chooses random exponents and computes . Next, TA sets as his master key and publishes the public parameter . Finally, TA creates two empty identity tables and .
KeyGen : DU submits his identity and attributes set to TA in order to apply for the user private key. TA first picks and sets . For each , TA picks and computes . Then, TA sets as DU private key and sends it to the DU with identity . Next, TA picks , sets as DO private key, and sends it to DO. After that, TA computes , stores in the registered identity table , and sends to CS for search permission revocation. Finally, TA adds in the identity table and secretly stores for user tracing.
Enc : to encrypt a keyword under an access policy , DO computes . For each , DO chooses such that , computes , and sets for each as follows: if , it sets ; otherwise, it sets and as two random elements in . Finally, DO uploads the ciphertext into the cloud.
TokenGen : to generate a search token for a keyword , DU picks and computes . For each , DU computes . Finally, DU sends the search token to CS.
Search : when CS receives the search token from the DU with identity , it first searches the entry in the table . If no such entry exists, CS returns 0 and aborts; otherwise, CS obtains from and runs the following search algorithm. If Algorithm. If , it computes . Finally, CS returns 1 if and 0 otherwise.
Trace : if the private key is not in the form of , TA returns and aborts; otherwise, TA runs the following key sanity check algorithm. .
If the private key does not pass the above check, TA returns and aborts; otherwise, TA searches the entry in table and returns the corresponding .
Revoke : to revoke the search permission of the malicious user with identity , TA updates table by deleting the entry and sends new table to CS.
4.2. Correctness Proof
We now prove the correctness of our TR-HABKS scheme. If Scheme. If the user attributes satisfy the access policy , we have and for each . Then,
If the user is in table , then CS can obtain the corresponding . Therefore,
In this case, if , we have
4.3. 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 . 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 , we consider three random encodings , where is an additive group and . For , let . Therefore, there are three oracles to compute the group action on and an oracle to compute the bilinear map . We refer to 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 that can break our TR-HABKS scheme with advantage in the selective security model. We will build a simulator that can break the QLSZ scheme with advantage . Let be the challenger corresponding to in the security game of QLSZ scheme. For more information about the QLSZ scheme and its security, please refer to . Inti: simulator receives two challenge access policies and from adversary and then sends these policies to challenger . Setup: sends the QLSZ public parameter to . Then, picks , sets , and sends the public parameter to . Query Phase1: answers the adversary’s private key and search token queries in our TR-HABKS scheme as follows:(1)Private key query : in order to create the user private key for a pair requested by , first sends to to query the corresponding user private key in QLSZ scheme. When receives the QLSZ private key , it picks , implicitly sets , , and sets . Then, it computes . Finally, sets the user private key and sends it to .(2)Search token query : in order to create the search token for a tuple requested by , first runs to obtain . Then, picks and computes , . Finally, sets the search token and sends it to . Challenge: submits two keywords and to , where the pair satisfies the following constraint. If the adversary has queried the private key or search token for the attributes set that satisfies both access policies and , then we require that . Next, sends and to to obtain the QLSZ challenge ciphertext . Finally, sets and returns the challenge ciphertext to . Query Phase2: same as Phase 1. Guess: finally, outputs a guess , and then sends to .According to the above simulation, if has advantage in the selective security game against our scheme, then can use 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 . In order to prove the traceability, we assume that there exists a PPT adversary who can win the traceability game, and then we construct a simulator that can break the BB basic signature scheme under a weak chosen message attack. Let denote the BB challenger corresponding to in the signature security game. For more information about the BB basic signature scheme and its security, please refer to .
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 sets a bilinear group . , and are the cyclic groups of prime order , is a generator of , is a generator of , and is a bilinear map.
Simulator first chooses random values and makes signature queries by submitting the values to challenger . Then, sends the BB public parameter and the corresponding signatures to . For each , chooses random exponents and computes . Next, picks and a one-way hash function and computes . Finally, sends the public parameter to adversary and initializes an empty identity table .
4.4.2. Key query
When makes user private key query for , first picks and sets . For each , picks and computes . Then, sets as the corresponding private key and returns it to . Finally, adds to .
4.4.3. Key forgery
Adversary outputs a user private key .
If wins the above traceability game, then Trace. Hence, the key satisfies the following conditions: , , and .
Assuming that , where and are unknown, we have , and then . Therefore, .
Finally, computes and then obtains a valid signature on message , where . Hence, if has advantage in the traceability game, then can forge a valid BB basic signature scheme with advantage under a weak chosen message attack.
5. 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.
5.1. Concrete System
5.1.1. System Initialization
In this phase, TA generates the system parameter, the master key for himself, and an identity table for revocation.
TA first runs to obtain . For each , TA chooses random exponents and computes . Then, TA picks and a one-way hash function . Next, TA sets as his master key and publishes the public parameter . Finally, TA creates an empty identity table .
5.1.2. 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 and attributes set to TA to apply for his private key. TA first picks and sets . For each , TA picks and computes . TA sets as the user private key and sends it to the corresponding DU. Then, TA picks and sets as the data owner private key and sends it to DO. Finally, TA computes , stores in the identity table , and sends to CS.
5.1.3. 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 from the file and encrypts the keyword under an access policy . DO first computes . For each , DO chooses such that , computes , and sets for each as follows: if , it sets ; otherwise, it sets as a random element in . Finally, DO stores the encrypted index in the cloud.
5.1.4. Search Token Generation
In this phase, DU generates a search token for a keyword , and sends the search token to CS for the data retrieval request.
DU first picks , computes . For each , DU computes . Finally, DU sets the search token .
5.1.5. 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 from DU, it first searches the entry in . If no such entry exists, CS returns error symbol and aborts; otherwise, CS obtains from and then runs the following search algorithm. If Algorithm. If , it computes . Finally, CS returns 1 if and 0 otherwise.
5.1.6. User Tracing
In this phase, TA traces the malicious user who sales his private key on the Internet and outputs the malicious user’s identity.
TA first checks whether is a well-formed key. If the private key is not in the form of , it returns and aborts; otherwise, it runs the following key sanity check algorithm. .
If does not pass the above check, it returns and aborts; otherwise, it returns as the corresponding user identity.
5.1.7. User Revocation
In this phase, TA revokes the search permissions of the malicious users. When TA obtains the malicious user identity , he updates table by deleting the entry and sends the new table to CS.
5.2. Correctness Proof
The correctness of our TR-HABKS scheme is proved as follows. If the user attributes satisfy the access policy , we have and for each . Then,
If the user is in the table , then CS has the corresponding . Therefore,
In this case, if , we have
The 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 . The length of the public parameter/ciphertext of all three schemes increases linearly with , where is the total number of attributes in the system and is the number of possible values for attribute index . 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 elements, respectively. The 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 is far less than , 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 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 . 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. , , and denote an exponentiation operation in groups