Abstract
The massive amounts of data collected by Internet of things (IoT) devices can be stored in clouds to solve the problem of the low storage capacity of IoT terminals. However, the privacy and security of outsourced IoT data may be compromised on the cloud side. Traditional cryptographic technologies can protect data privacy but require the user to retrieve the data for decryption and further processing, which would bring vast amounts of bandwidth and computation burden to users. This paper proposes a dual-server identity-based encryption scheme supporting authorized ciphertext equality test (DS-IBE-AET), where two noncolluding servers with authorizations from users can collaboratively carry out an equality test on outsourced IoT ciphertexts without decrypting the data. DS-IBE-AET can resist offline keyword guessing attacks confronted by existing encryption schemes with equality test in the single server model. Security analysis demonstrates that the proposed DS-IBE-AET scheme offers unforgeability for private keys of users and servers and confidentiality protection for outsourced IoT data and authentication tokens. The performance analysis indicates the practicality of our DS-IBE-AET construction for securing outsourced IoT data in clouds.
1. Introduction
With the advancement of cloud computing, various types of user data produced in the Internet of things, Internet of vehicles, smart grid and other applications can be maintained in the cloud to reduce the local storage costs. In order to protect data privacy on cloud servers, the most common and effective method is to encrypt data, then upload encrypted data to servers. Traditional data encryption technologies can ensure data confidentiality; however, they would make encrypted data unsearchable and incomparable [1, 2]. Thus, users have to retrieve the data from remote cloud servers, then decrypt it for processing. This will not be able to take advantage of the powerful computing resources of the cloud server and bring huge computing overhead to users.
To solve this problem, Boneh et al. [3] proposed a public key encryption scheme with keyword search (PEKS), where the keyword is encrypted and outsourced along with the encrypted message so that it can be compared with the encrypted trapdoor for realizing privacy-preserving search over the outsourced data. Particularly, the search process relies on the equality test between the encrypted keyword and trapdoor. In 2010, Yang et al. [4] presented a public key encryption scheme withequality test (PKEET), which allowed the cloud server to check whether two ciphertexts had the same plaintext without decryption. Here, these ciphertexts may be generated by different users with different public keys. Since then, many variants supporting ciphertext equality tests with different functions and characteristics have been introduced [5–8].
However, most of these schemes supporting equality tests on outsourced ciphertexts are proposed in the single server model, which cannot resist offline keyword guessing attacks. That is, the cloud server is able to generate ciphertext for any message in the message space in the public key setting, then after being authorized, it can perform the equality test procedure with outsourced ciphertexts. In this way, the cloud server would find all the ciphertexts that encrypted the chosen message through the equality test procedure. Therefore, the confidentiality of these outsourced ciphertexts is compromised. To address this issue, Zhao et al. [9] proposed a public key encryption scheme with authorized equality test in the dual-server model, where the outsourced data is only stored at the primary server and two servers would not collude to launch attacks against user data. However, since their scheme is designed for as public key setting, they confront complex certificate management problems. Also, Wu et al. [10] designed an identity-based scheme supporting equality test in a dual-server model, while the privacy of the authentication token was not considered.
1.1. Our Contributions
In this paper, we propose a dual-server identity-based encryption scheme supporting authorized equality tests on outsourced IoT ciphertexts (DS-IBE-AET). As in the dual-server model of [9, 10], the front server and back server would not launch collusion attacks to compromise the confidentiality of outsourced IoT data, where these data are only kept at the front server. The equality test procedures can be executed in sequence only after both servers have obtained user authorizations, which can also be conducted in a multiuser setting with the authorizations from different users. The back server can only get internal test results from the front server, which makes it impossible to deduce the information from user data.
In our DS-IBE-AET construction, the encrypted authorization tokens for two servers are in the same format, which should be decrypted using the respective secret key for performing equality test procedures. Compared to [9, 10], our DS-IBE-AET construction designed for the identity-based setting avoids the burden of certificate management. Security analysis demonstrates that the proposed DS-IBE-AET construction guarantees the unforgeability of users’ and servers’ private keys, the privacy of outsourced data against two servers, as well as the privacy of authorization tokens. The performance analysis indicates that the proposed DS-IBE-AET construction is practical in IoT-related applications.
1.2. Related Works
Public key encryption with equality test is closely related to PEKS. Boneh et al. [3] introduced PEKS to allow the e-mail gateway to test whether the e-mail contained some special keywords, where the gateway did not need to decrypt emails. The main idea behind PKES is to test the equality of the encrypted keywords and trapdoor. PKEET was first introduced by Yang et al. [4], which allows any entity to perform an equality test on two ciphertexts to determine whether they were generated by the same plaintext, where the ciphertexts may be produced with different public keys. The ciphertext equality test technology has been extensively used in different scenarios, for example, privacy-preserving equi-join in relational databases [7, 11], secure deduplication on cloud data [12, 13], implicit authentication [14], and privacy-preserving road condition monitoring [15].
Since the outsourced ciphertexts can be publicly compared in Yang et al.‘s PKEET [4], many solutions supporting authentication mechanisms have been developed. Tang introduced the AoN-PKEET [16] and FG-PKEET [17] to realize coarse-grained and fine-grained authorization for ciphertext equality tests, respectively. Wang et al. [18] presented a public key signcryption scheme with designated equality test to secure messaging services. Lee et al. [19] presented a generic PKEET construction by employing a two-level hierarchical identity-based encryption scheme, a strongly unforgeable one-time signature scheme, and a cryptographic hash function, whose security can be proved in the standard model. Attribute-based and proxy encryption schemes supporting authorized equality testing on ciphertexts had been studied in [20, 21], respectively. Compared with our DS-IBE-AET construction in the dual-server model, these schemes were designed in a public key setting, which faced the complex certificate management problem and cannot resist offline keyword guessing attacks.
Many identity-based encryption schemes (IBE) with ciphertext equality tests (IBEET) have been presented, which can mitigate the complexity of public key certificate management in PKEET. Ma [22] first introduced IBEET by combining PKEET and IBE. Wu et al. [23] put forward a novel IBEET scheme, in which users are divided into different groups, and only the users in the same group can generate ciphertexts with the shared secret token. In [24], Lee et al. noted that Wu et al.’s scheme [23] cannot resist insider attack and presented an improved IBEET construction. Alornyo et al. [25] constructed an IBEET from witness-based encryption technology to resist insider attacks, which offered weak indistinguishability under chosen ciphertext attacks in the random oracle model. Ling et al. [26] introduced group IBEET, where only the group administrator was able to issue authorization tokens to the tester. Compared with our DS-IBE-AET construction in the dual-server model, these schemes engage only a single cloud server, which cannot resist offline keyword guessing attacks.
The dual-server model has been generally employed in designing secure and privacy-preserving systems for resisting keyword guessing attacks launched by cloud servers, where two semitrusted servers would not collude with each other [27]. In [28], Tang introduced an amended FG-PKEET scheme in the two-proxy setting, where the equality test procedure had to be interactively carried out by two proxies. In this way, the ciphertexts can be protected against offline message recovery attacks. Wu et al. [10] proposed a dual-server identity-based encryption with equality test for mobile health social networks, in which two servers with authentication tokens can collaborate to complete the ciphertext equality test, while the privacy of the authentication token was not considered. Recently, Zhao et al. [9] proposed a public key encryption construction supporting authorized equality test on outsourced IoT data in a non-colluding dual-server model. Compared with [9], our DS-IBE-AET construction is developed in an identity-based setting, which can avoid the complex certificate management problem.
1.3. Paper Organization
The remainder of this paper is structured as follows. Section 2 reviews the preliminaries. The system model, security requirements, and system framework are introduced in Section 3. A concrete DS-IBE-AET scheme is presented in Section 4, while security and performance are analyzed in Section 5. Finally, the paper is concluded in Section 6.
2. Preliminaries
2.1. Bilinear Groups
Suppose and are two cyclic groups of prime order . The mapping is a bilinear pairing if the following conditions are satisfied:
2.1.1. Bilinearity
For any and ,
2.1.2. Non-Degeneracy
There exists such that,
2.1.3. Efficiency
For , there exists an efficient algorithm to compute .
2.2. Complexity Assumptions
The security of our DS-IBE-AET construction relies on the following complexity assumptions.
CDH assumption. Suppose is a cyclic group of prime order . Given a tuple where , no probabilistic polynomial-time algorithm can compute with nonnegligible probability.
CBDH assumption. Suppose and are two cyclic groups of prime order and satisfy bilinear pairing . Given a tuple where , no probabilistic polynomial-time algorithm can compute with nonnegligible probability.
3. System Model and Security Requirements
3.1. System Model
As shown in Figure 1, in a DS-IBE-AET system, there are three types of entities, namely, a key generation center (KGC), users, and servers. KGC is an honest entity that is responsible for initializing the DS-IBE-AET system by producing the master private key and public parameters. It also issues the private keys for all users , the front server and back server according to their identities, respectively.
In the DS-IBE-AET system, both the data sender and the data recipient are system users. The data sender encrypts the data using the identity of the data recipient and the system public parameters, and the generated ciphertexts are only sent to the front server for storage. The data recipient is able to retrieve ciphertexts from the front server and run the decryption procedure using his/her private key. Also, a data recipient is able to authorize the front server and back server to perform equality test on his/her ciphertexts without decryption. The authorization tokens are encrypted using the identities of two servers, so that they can only be decrypted by the two servers.
The front server has huge storage resources for maintaining user data in ciphertext format. Both the front server and back server have powerful computing capabilities for collaboratively performing equality tests on user ciphertexts after being authorized. With the authorizations from users, the front server is able to generate internal results of equality tests on ciphertexts, which are then sent to the back server to further confirm whether two ciphertexts encrypt the same message. The authorization tokens only allow two servers to collaboratively perform equality tests on users’ ciphertexts.
3.2. Security Requirements
In the DS-IBE-AET system, the front server and back server would not launch collusion attacks to compromise the privacy of user ciphertexts. A secure DS-IBE-AET system must meet the following security conditions:
3.2.1. Unforgeability of User Private Key
The private key generated by KGC for user cannot be forged by any entity.
3.2.2. Unforgeability of Server Private Key
The private keys generated by KGC for the front server and back server cannot be forged by any entity.
3.2.3. Data Privacy against the front Server
The front server cannot deduce the private information of users from the stored ciphertexts before and after being authorized by users to perform equality tests.
3.2.4. Data Privacy against the Back Server
After obtaining the users’ authorizations for performing the equality test, the back server cannot deduce the private information of users from the received internal results.
3.2.5. Privacy Protection on Authentication Token
The authentication tokens generated for the front server and back server can only be decrypted by themselves, respectively.
3.3. System Framework
A DS-IBE-AET scheme consists of nine polynomial-time procedures, namely, Setup, UKeyExt, SKeyExt, Encrypt, Decrypt, Authen, DecAuth, , and .
3.3.1. Setup
On input of the security parameter , the system setup procedure, which is run by KGC, generates the system master private key and system public parameters . We denote . Note that is the implicit input for the following eight procedures.
3.3.2. UKeyExt
On input of the master private key and a user identity , the user key extraction procedure, which is run by KGC, generates a private key for user . We denote .
3.3.3. SKeyExt
On input of the master private key and the identity of the front server (resp. of the back server), the server key extraction procedure, which is run by KGC, generates a private key for the front server (resp. for the back server ). We denote .
3.3.4. Encrypt
On input of the identity of the data recipient and a message , the data encryption procedure, which is performed by the data sender, generates a ciphertext and sends it to the front server . We denote (, ).
3.3.5. Decrypt
On input of the private key of the data recipient and a ciphertext , the data decryption procedure, which is performed by data recipient, outputs a plaintext or that signifies an error in decryption. We denote / Decrypt(, ).
3.3.6. Authen
On input of the private key of user and the identities (, ) of the front server and back server, the authentication token generation procedure, which is carried out by the user , generates ciphertext authentication tokens and for two servers. Note that the tokens and are sent to the front server and back server , respectively. We denote .
3.3.7. DecAuth
On input of the private key of the front server (resp. of the back server ) and a ciphertext authentication token (resp. ), the authentication decryption procedure, which is performed by the front server (resp. the back server ), outputs a plaintext authentication token (resp. ) or that signifies an error in decryption. We denote for the front server and for the back server .
3.3.8.
On input of the plaintext authentication tokens and of two users and , respectively, and their ciphertexts and , the front equality test procedure, which is performed by the front server , outputs an internal result and sends it to the back server . We denote .
3.3.9.
On input of the plaintext authentication tokens and of two users and , respectively, and an internal result , the back equality test procedure, which is performed by the back server , outputs if and encrypt the same message or otherwise. We denote .
A DS-IBE-AET construction must be sound in the sense that if the procedures are performed honestly, the following conditions hold:(i)The private key extracted by KGC for some users can be validated by such a user.(ii)The private key extracted by KGC for each server can be validated by such a server.(iii)The ciphertext generated by the data encryption procedure can be decrypted by the data decryption procedure.(iv)The ciphertext authentication token generated by the authentication token generation procedure can be decrypted by the authentication decryption procedure.(v)For any two ciphertexts that encrypt the same message, which may belong to different users, the front and back equality test procedures can collaboratively output .(vi)For any two ciphertexts that encrypt different messages, which may belong to different users, the front and back equality test procedures collaboratively output with overwhelming probability.
Definition 1. (Soundness): A DS-IBE-AET construction is sound if, for any security parameter , any master private key and public parameters , any private keys , of two users and , any private key of the front server , and any private key of the back server , the following conditions are satisfied:(i)The private key can be verified as valid in the verification step by the user .(ii)The private key can be verified as valid in the verification step by the front server , and the private key can be verified as valid in the verification step by the back server .(iii)For any message , .(iv) and , where .(v)For any two messages , such that (, ) and (, ), if , then = , otherwise , where , , , , , , , and represents a negligible function.
4. Concrete DS-IBE-AET Construction
This section presents a concrete DS-IBE-AET construction in bilinear groups, where a running process is shown in Figure 2, and the frequently used symbols are summarized in Table 1.
4.1. System Setup
Given a security parameter , KGC chooses cyclic groups and satisfying bilinear mapping , where groups and have prime order . KGC selects four cryptographic hash functions , , and , where and , respectively, denote the element size in group and message space. Also, KGC picks three random elements and computes the following:
At last, KGC keeps the master private key secret and publishes the public parameter .
4.2. User Key Extraction
Given the identity of user , KGC generates the private key as follows:
The private key is sent to the user via secure channel. Note that the user is able to validate as follows:
4.3. Server Key Extraction
Given the identity of the front server , KGC generates the private key as follows:which is sent to the front server via secure channel. Note that the front server is able to validate as follows:
Similarly, KGC can generate the private key for the back server as follows:and the back server is able to validate as follows:
4.4. Data Encryption
For a message , the sender randomly picks an element , and computes the ciphertext , where
The ciphertext is sent to the front server .
4.5. Data Decryption
For ciphertext , the user decrypts it with the private key as follows. The user
computes the following:
Next, the user checks whether both of the following equalities hold:
If so, is outputted, otherwise is outputted.
4.6. Authorization
The user randomly picks an element and computes the following:
Then, the encrypted authorization tokens and are sent to the front server and to the back server , respectively.
4.7. Token Decryption
Given the encrypted authorization token , the front server computes the following equation:
The back server can decrypt the token in the similar way as follows:then, these two servers are able to validate the recovered tokens as in (5) and (6), respectively.
4.8. Front Server Ciphertext Test
For the ciphertexts and of two users and , respectively, the front server generates the internal test result with their respective tokens and . The front server computes the following equation:then, it computesthe internal test result is sent to the back server .
4.9. Back Server Ciphertext Test
For the internal test result on the ciphertexts of users and , the back server checks the following equality with the received tokens and :if it holds, then “1” is outputted, which means the two ciphertexts and ' of users and encrypt the same message; otherwise “0” is outputted, which means different messages are encrypted in two ciphertexts.
Theorem 1. The proposed DS-IBE-AET construction in bilinear groups is sound.
Proof. 1 First, for the first element in the private key of user , the equality in (1) holds as follows:The equalities in (6) and (7) for the other two elements and can be verified in the similar way.
Second, for the private key for the front server , the equality in (9) holds as follows:The equality in (11) for the back server can be verified in the similar way.
Third, for the correctness of decryption on user ciphertexts, sincewe havethus, the equalities (15) and (16) hold, which means the message can be successfully decrypted.
Four, for the authorization token decryption, it can be seen thatThus, the tokens for the front server and back server can be correctly decrypted as in (19) and (20).
Five, for an authorized equality test on ciphertexts, sincewe haveIt can be seen that if the messages and ' are the same, then the equality in (24) holds.
Therefore, the proposed DS-IBE-AET construction in bilinear groups is sound.
5. Analysis and Comparison
5.1. Security Analysis
Theorem 2. The proposed DS-IBE-AET construction in the dual-server model can guarantee the unforgeability of the private keys of users.
Proof. 2 As shown in Sections 4.2, the private keys of users are generated by KGC using their private keys . Particularly, each element of the private key is a signature on the user’s identity with the short signature scheme of Boneh et al [29]. Therefore, according to the security result that the BLS signature scheme is secure against existential forgery under adaptive chosen-message attacks in the random oracle model assuming the CDH assumption holds [29], Theorem 3.2, the proposed DS-IBE-AET scheme can protect the unforgeability of private keys of users.
Theorem 3. The proposed DS-IBE-AET construction in the dual-server model can guarantee the unforgeability of the private keys of both servers.
Proof. 3 Similar to the analysis for Theorem 2, the private keys of both servers are generated by KGC using their private keys by employing the short signature scheme of Boneh et al [29]. Thus, according to the security result of [29], Theorem 3.2, the proposed DS-IBE-AET scheme can protect the unforgeability of the private keys of two servers.
Theorem 4. The proposed DS-IBE-AET construction in the dual-server model can guarantee the privacy of outsourced data against the front server.
Proof. 4 As shown in Section 4.4, the ciphertext in the proposed DS-IBE-AET scheme has a similar form as Lee et al.'s PKE-AET scheme [30]. Note that their scheme is designed in generic cyclic groups, and our DS-IBE-AET scheme is developed in bilinear groups in an identity-based setting. Moreover, the pair can be seen as an extension of the ciphertext in Boneh and Franklin’s basic IBE scheme [31], Section 4. For the second component of our ciphertext, two public parameters and are used, which would be used to enable both the front server and back server to collaboratively perform equality tests on ciphertexts; while only one public key is used in producing in Lee et al.'s PKE-AET scheme [30], since their scheme is considered in the single server model. Therefore, before the front server gets authorized, the proof for the privacy of outsourced data follows [30], Theorem 4.1 and [31], Theorem 4.1, that is, the proposed DS-IBE-AET scheme offers indistinguishability against chosen ciphertext and chosen identity attacks (IND-ID-CCA security) for the front server under the CDH and CBDH assumptions. When the front server is authorized, it would get the authorization token for performing an equality test on ciphertexts. Thus, the proposed DS-IBE-AET scheme offers one-wayness security against chosen ciphertext attacks and chosen identity attacks [31, 32] under the CDH and CBDH assumptions.
Theorem 5. The proposed DS-IBE-AET construction in the dual-server model can guarantee the privacy of outsourced data against the back server.
Proof. 5 In the proposed DS-IBE-AET scheme, the outsourced ciphertexts are only stored at the front server. When collaboratively performing equality tests on ciphertexts, only the intermediate result is given to the back server by the front server. Note that is computed from and '. As shown in equations (12) and (13), and ' have a similar form of in ciphertext of Lee et al.'s scheme [30], but in an identity-based setting [31]. That is, the pairs and have a similar form of in Lee et al.'s scheme [30] and Boneh and Franklin’s basic IBE scheme [31], Section 4. Thus, the proof is similar to that in [30], Theorem 4.1, and [31], Theorem 4.1, that is, the proposed DS-IBE-AET scheme is IND-ID-CCA secure against the back server under the CDH and CBDH assumptions.
Theorem 6. The proposed DS-IBE-AET construction in the dual-server model can guarantee the privacy of an authentication token.
Proof. 6 The ciphertext authentication token in the proposed DS-IBE-AET construction is generated in a similar way as the ciphertexts in Boneh and Franklin’s basic IBE scheme [31], Section 4. The difference is that is used to construct two encrypted authorization tokens and for two servers, respectively. Thus, the proof is similar to that in [31], Theorem 4.1, that is, the authentication token in the proposed DS-IBE-AET construction enjoys indistinguishability against chosen plaintext and chosen identity attacks under the CBDH assumption.
5.2. Performance Analysis
In this section, we analyze the efficiency of our DS-IBE-AET construction in each procedure and compare with Zhao et al.'s construction [9] in terms of resource-intensive operations such as exponentiation, bilinear pairing, and the map-to-point hash function. As shown in Table 2, let denote the evaluation cost of an exponentiation in group , represent the evaluation cost of a bilinear pairing and signify a map-to-point hash function, respectively.
Since our DS-IBE-AET construction is developed in an identity-based setting, the private keys of users and servers are generated by the trusted KGC, where the computational cost of generating a private key for a user is times the cost for a server. Users and servers only need to verify the correctness of the issued private keys, respectively. Note that these private keys should be delivered via a secure channel, thus the verification process can be omitted by the respective users and servers. While in Zhao et al.'s construction [9], the private keys are produced by respective user and server, which take and exponentiation operations on the bilinear group , respectively.
To facilitate the analysis of the data encryption procedure, the exponentiation operation in group in both schemes is converted to first computing the exponentiation operation in group and then performing the bilinear pairing operation , which can enable intermediate calculated parameters to be reused and reduce computing costs. Hence, the Encrypt procedure of our DS-IBE-AET scheme takes two less exponentiation operations than that in Zhao et al.'s construction [9] when encrypting a message. Since our DS-IBE-AET scheme is designed in an identity-based setting, it takes one more bilinear pairing and map-to-point hash function evaluation than [9]. For decrypting a ciphertext, although our DS-IBE-AET scheme takes one more bilinear pairing operation than Zhao et al.'s construction [9], it only requires one exponentiation operation, whereas the latter needs to carry out exponentiation operations.
In the authentication phase, our DS-IBE-AET scheme allows the user to generate different tokens for two servers. Note that these tokens have the same form and share one element . Thus, the computing cost for generating can be shared by two tokens. Also, the exponentiation operation of can be reused in producing both and .
As shown in (17) and (18), the generation of and , respectively, requires two time-consuming map-to-point hash operations. While in Zhao et al.'s construction [9], two servers shall be authenticated with the same token; that is, the servers would recover the same token with the only difference that their respective private keys would be used during decryption. Moreover, since the authentication token is in fact an element of the user’s private key, it can be validated according to the relationship with the corresponding public key.
After being authorized, the front server and back server are able to cooperatively carry out equality tests on outsourced ciphertexts. On both server sides, our DS-IBE-AET scheme is much more efficient than Zhao et al.'s construction [9], where no exponentiation operations are required in our DS-IBE-AET scheme. Specifically, to perform an equality test on one pair of ciphertexts, both servers in Zhao et al.'s construction [9] should take more exponentiation operations than those in our DS-IBE-AET scheme, which is due to the fact that the private keys of these servers should be used in their respective procedures. It can be seen that the computing costs for the equality test in both schemes are linear with the number of compared ciphertexts.
Moreover, we evaluate the performance of our DS-IBE-AET scheme and compare it with Zhao et al.'s construction [9], where the experimental execution times of cryptographic operations in [33] are used. The experiments of [33] were carried out on a platform with a Windows 7 operating system, an Intel [email protected] GHz CPU, and 4 GB of memory, where the MIRACL Cryptographic SDK [34] was run with . The exact execution times of three resource-intensive cryptographic operations are shown in Table 3.
The performance of private key extraction procedures of our DS-IBE-AET scheme and the key generation procedure of Zhao et al.'s construction [9] are depicted in Figure 3. It can be seen that in our DS-IBE-AET scheme, the verification procedures at both the user and server sides take more time than KGC. Note that the private keys for users and servers only need to be extracted once; the computational costs for them are affordable. In Zhao et al.'s construction [9], users and servers can generate private keys for themselves in less than milliseconds, and there is no verification procedure.
The performance of other procedures is depicted in Figure 4, where the case for each procedure to be executed once is considered for both schemes. To encrypt a message, the proposed DS-IBE-AET scheme will take milliseconds more than Zhao et al.'s construction [9], while our data decryption procedure is more efficient. Since the encryption of the authentication token in our scheme is designed in an identity-based setting, it would take more time to encrypt, decrypt, and validate the token than that in Zhao et al.'s construction [9]. For collaboratively performing equality test on two ciphertexts, both the front and back servers roughly take milliseconds less than Zhao et al.'s construction [9].
The comparison on communication costs between our DS-IBE-AET construction and Zhao et al.'s scheme [9] is shown in Table 4, in terms of the sizes of the user private key, server private key, ciphertext, authorization token, and internal equality test results. Since our DS-IBE-AET construction is designed in an identity-based setting, it requires KGC to issue the private keys for users and servers. As shown in Table 4, each user’s private key in our scheme contains three elements in group and each server’s private key contains only one element in group . While for the scheme from Zhao et al. [9], it was developed in a public key setting and the private keys can be respectively generated by each user and server. However, it is well-known that the corresponding public keys for the users and servers should be maintained through the public key infrastructure.
For the ciphertext corresponding to a message, both our DS-IBE-AET construction and Zhao et al.'s scheme [9] are composed of three elements of the same size and enjoy the same communication costs. For the authorization phase, our DS-IBE-AET construction sends different authorization tokens of the same size of to each server. Whereas in Zhao et al.'s scheme [9], the two servers would receive an identical authorization token containing one element in group and one element in . In the equality test phase, both schemes require the front server to deliver the internal test result to the back server, which comprises three elements in group for comparing a pair of ciphertexts.
6. Conclusion
This paper proposed an identity-based encryption with authorized equality test on ciphertexts in a dual-sever setting (DS-IBE-AET), which addressed the complicated certificate management problem in existing proposals supporting equality test on ciphertexts in a public key setting. Particularly, the proposed DS-IBE-AET construction can resist keyword guessing attacks on outsourced ciphertexts that are only stored on the front server side. Only after obtaining the authentication from users would the front server and back server be able to collaboratively perform equality tests on the ciphertexts of these users, where the front server generates an internal test result for further confirmation by the back server. Security analysis demonstrated that the presented DS-IBE-AET scheme can protect the privacy of outsourced ciphertexts and authentication tokens, and performance analysis showed the practicality of our DS-IBE-AET scheme.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This article was supported by the Guangxi Natural Science Foundation under grants 2019GXNSFFA245015 and 2019GXNSFGA245004, the National Natural Science Foundation of China under projects 62162017 and 62172119, and the Peng Cheng Laboratory Project of Guangdong Province PCL2021A09, PCL2022A02, and PCL2021A03.