Dual-Server Identity-Based Encryption with Authorized Equality Test for IoT Data in Clouds

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 oﬄine 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 oﬀers unforgeability for private keys of users and servers and conﬁdentiality protection for outsourced IoT data and authentication tokens. The performance analysis indicates the practicality of our DS-IBE-AETconstruction for securing outsourced IoTdata in clouds.


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]. us, users have to retrieve the data from remote cloud servers, then decrypt it for processing. is 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][6][7][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. at 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. erefore, 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.

Our Contributions.
In this paper, we propose a dualserver 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. e 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. e 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. e performance analysis indicates that the proposed DS-IBE-AET construction is practical in IoT-related applications.

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. e 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. e 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.
e 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 identitybased setting, which can avoid the complex certificate management problem.

Paper Organization.
e remainder of this paper is structured as follows. Section 2 reviews the preliminaries. e 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.

Preliminaries
2.1. Bilinear Groups. Suppose G � < g > and G T are two cyclic groups of prime order q. e mapping e: G × G ⟶ G T is a bilinear pairing if the following conditions are satisfied: (1)

Complexity
Assumptions. e security of our DS-IBE-AET construction relies on the following complexity assumptions.
CDH assumption. Suppose G � < g > is a cyclic group of prime order q. Given a tuple (g, g a , g b ) where a, b∈ R Z * q , no probabilistic polynomial-time algorithm A can compute g ab with nonnegligible probability.
CBDH assumption. Suppose G � < g > and G T are two cyclic groups of prime order q and satisfy bilinear pairing e: G × G ⟶ G T . Given a tuple (g, g a , g b , g c ) where a, b, c∈ R Z * q , no probabilistic polynomial-time algorithm A can compute e(g, g) abc with nonnegligible probability. 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 S f and back server S b according to their identities, respectively.

System Model. As shown in
In the DS-IBE-AET system, both the data sender and the data recipient are system users. e 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 S f for storage. e data recipient is able to retrieve ciphertexts from the front server S f and run the decryption procedure using his/her private key. Also, a data recipient is able to authorize the front server S f and back server S b to perform equality test on his/her ciphertexts without decryption. e authorization tokens are encrypted using the identities of two servers, so that they can only be decrypted by the two servers.
e front server S f has huge storage resources for maintaining user data in ciphertext format. Both the front server S f and back server S b have powerful computing capabilities for collaboratively performing equality tests on user ciphertexts after being authorized. With the authorizations from users, the front server S f is able to generate internal results of equality tests on ciphertexts, which are then sent to the back server S b to further confirm whether two ciphertexts encrypt the same message. e authorization tokens only allow two servers to collaboratively perform equality tests on users' ciphertexts.

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:

Unforgeability of User Private Key.
e private key generated by KGC for user cannot be forged by any entity.

Unforgeability of Server Private Key.
e private keys generated by KGC for the front server S f and back server S b cannot be forged by any entity.

Data Privacy against the front Server.
e front server S f cannot deduce the private information of users from the stored ciphertexts before and after being authorized by users to perform equality tests.

Data Privacy against the Back Server.
After obtaining the users' authorizations for performing the equality test, the back server S b cannot deduce the private information of users from the received internal results.

Privacy Protection on Authentication Token.
e authentication tokens generated for the front server S f and back server S b can only be decrypted by themselves, respectively.

Setup.
On input of the security parameter δ, the system setup procedure, which is run by KGC, generates the system master private key mpk and system public parameters param. We denote (mpk, param)←Setup(1 δ ). Note that param is the implicit input for the following eight procedures.

UKeyExt.
On input of the master private key mpk and a user identity ID i , the user key extraction procedure, which is run by KGC, generates a private key usk i for user ID i . We denote usk i ←UKeyExt(mpk, ID i ).

SKeyExt.
On input of the master private key mpk and the identity S f of the front server (resp. S b of the back server), the server key extraction procedure, which is run by KGC, generates a private key ssk f for the front server S f (resp. ssk b for the back server S b ). We denote

Encrypt.
On input of the identity ID i of the data recipient and a message m, the data encryption procedure, which is performed by the data sender, generates a ciphertext c and sends it to the front server S f . We denote c←Encrypt(ID i , m).

Decrypt.
On input of the private key usk i of the data recipient ID i and a ciphertext c, the data decryption procedure, which is performed by data recipient, outputs a plaintext m or ⊥ that signifies an error in decryption. We denote m/ ⊥ ← Decrypt(usk i , c).
3.3.6. Authen. On input of the private key usk i of user ID i and the identities (S f , S b ) of the front server and back server, the authentication token generation procedure, which is carried out by the user ID i , generates ciphertext authentication tokens t i,f and t i,b for two servers. Note that the tokens t i,f and t i,b are sent to the front server S f and back server 3.3.7. DecAuth. On input of the private key ssk f of the front server S f (resp. ssk b of the back server S b ) and a ciphertext authentication token t i,f (resp. t i,b ), the authentication decryption procedure, which is performed by the front server S f (resp. the back server S b ), outputs a plaintext authentication token τ i,f (resp. τ i,b ) or ⊥ that signifies an error in decryption. We denote τ i,f /⊥←DecAuth(ssk f , t i,f ) for the front server S f and τ i,b /⊥←DecAuth(ssk b , t i,b ) for the back server S b .

EqTest f .
On input of the plaintext authentication tokens τ i,f and τ j,f of two users ID i and ID j , respectively, and their ciphertexts c and c ′ , the front equality test procedure, which is performed by the front server S f , outputs an internal result Γ and sends it to the back server S b . We denote On input of the plaintext authentication tokens τ i,b and τ j,b of two users ID i and ID j , respectively, and an internal result Γ, the back equality test procedure, which is performed by the back server S b , outputs 1 if c and c ′ encrypt the same message or 0 otherwise. We denote 1/0←EqTest b (τ i,b , τ j,b , Γ).
A DS-IBE-AET construction must be sound in the sense that if the procedures are performed honestly, the following conditions hold: (i) e private key extracted by KGC for some users can be validated by such a user. (ii) e private key extracted by KGC for each server can be validated by such a server. (iii) e ciphertext generated by the data encryption procedure can be decrypted by the data decryption procedure. (iv) e 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 1.

Concrete DS-IBE-AET Construction
is 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.

System Setup.
Given a security parameter δ, KGC chooses cyclic groups G � < g > and G T satisfying bilinear mapping e: G × G ⟶ G T , where groups G and G T have prime order q. KGC selects four cryptographic hash functions where ξ G and ξ m , respectively, denote the element size in group G and message space. Also, KGC picks three random elements d 1 , d 2 , d 3 ∈ Z * q and computes the following: At last, KGC keeps the master private key mpk � (d 1 , d 2 , d 3 ) secret and publishes the public parameter param � (δ, G, G T , q, e, g, H 1 , H 2 , H 3 , H 4 , V 1 , V 2 , V 3 ).

User Key Extraction.
Given the identity of user ID i , KGC generates the private key usk i � (usk i,1 , usk i,2 , usk i,3 ) as follows: e private key usk i is sent to the user ID i via secure channel. Note that the user ID i is able to validate usk i as follows:

Server Key Extraction.
Given the identity of the front server S f , KGC generates the private key as follows: which is sent to the front server S f via secure channel. Note that the front server S f is able to validate ssk f as follows: Similarly, KGC can generate the private key for the back server S b as follows: and the back server S b is able to validate ssk b as follows:

Data Encryption.
For a message m ∈ 0, 1 { } ξ m , the sender randomly picks an element α ∈ Z * q , and computes the ciphertext c � (c 1 , c 2 , c 3 ), where e ciphertext c is sent to the front server S f .

Data Decryption.
For ciphertext c � (c 1 , c 2 , c 3 ), the user ID i decrypts it with the private key usk i as follows. e user ID i computes the following: Next, the user ID i checks whether both of the following equalities hold: T � H 2 (m ′ ).
If so, m ′ is outputted, otherwise ⊥ is outputted.

4.6.
Authorization. e user ID i randomly picks an element c ∈ Z * q and computes the following: en, the encrypted authorization tokens t i,f � (t 0 , t 1 ) and t i,b � (t 0 , t 2 ) are sent to the front server S f and to the back server S b , respectively.

Token Decryption.
Given the encrypted authorization token t i,f , the front server S f computes the following equation: e back server S b can decrypt the token usk i,b in the similar way as follows: then, these two servers are able to validate the recovered tokens as in (5) and (6), respectively.   Private key of user ID i ssk f , ssk b Private keys of Ciphertext authentication tokens of user ID i for S f and S b τ i,f′ τ i,b Plaintext authentication tokens of user ID i for S f and S b Γ � (c 1 , c 1 ′ , ϖ) Internal test result of equality test then, it computes the internal test result Γ � (c 1 , c 1 ′ , ϖ) is sent to the back server S b .

Back Server Ciphertext Test. For the internal test result
Γ � (c 1 , c 1 ′ , ϖ) on the ciphertexts of users ID i and ID j , the back server S b checks the following equality with the received tokens τ i,b and τ j,b : if it holds, then "1" is outputted, which means the two ciphertexts c and c' of users ID i and ID j encrypt the same message; otherwise "0" is outputted, which means different messages are encrypted in two ciphertexts.

Theorem 1. e proposed DS-IBE-AET construction in bilinear groups is sound.
Proof. 1 First, for the first element usk i,1 in the private key usk i of user ID i , the equality in (1) holds as follows: e equalities in (6) and (7) for the other two elements usk i,2 and usk i,3 can be verified in the similar way.
Second, for the private key ssk f for the front server S f , the equality in (9) holds as follows: e equality in (11) for the back server S b can be verified in the similar way.
ird, for the correctness of decryption on user ciphertexts, since we have thus, the equalities (15) and (16) hold, which means the message m can be successfully decrypted. Four, for the authorization token decryption, it can be seen that 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. e 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 Γ � (c 1 , c ′ 1 , ϖ) 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 c 2 in ciphertext of Lee et al.'s scheme [30], but in an identity-based setting [31]. at is, the pairs (c 1 , c) and (c ′ 1 , c ′ ) have a similar form of (c 1 , c 2 ) in Lee et al.'s scheme [30] and Boneh and Franklin's basic IBE scheme [31], Section 4. us, the proof is similar to that in [30], eorem 4.1, and [31], eorem 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. Proof. 6 e 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. e difference is that t 0 is used to construct two encrypted authorization tokens t i,f � (t 0 , t 1 ) and t i,b � (t 0 , t 2 ) for two servers, respectively. us, the proof is similar to that in [31], eorem 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.

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 ℓ E denote the evaluation cost of an exponentiation in group G, ℓ P represent the evaluation cost of a bilinear pairing e(·, ·) and ℓ H 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 3 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 3 and 2 exponentiation operations on the bilinear group G, respectively.
To facilitate the analysis of the data encryption procedure, the exponentiation operation in group G T in both schemes is converted to first computing the exponentiation operation in group G and then performing the bilinear pairing operation e(·, ·), 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 identitybased setting, it takes one more bilinear pairing and map-topoint 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 4 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 t 0 . us, the computing cost for generating t 0 can be shared by two tokens. Also, the exponentiation operation of V c 1 can be reused in producing both t 1 and t 2 .
As shown in (17) and (18), the generation of t 1 and t 2 , 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 4 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. e experiments of [33] were carried out on a platform with a Windows 7 operating system, an Intel I7-4700@3.40 GHz CPU, and 4 GB of memory, where the MIRACL Cryptographic SDK [34] was run with log q � 512. e exact execution times of three resource-intensive cryptographic operations are shown in Table 3. e 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 6 milliseconds, and there is no verification procedure. e 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 5 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 7 milliseconds less than Zhao et al.'s construction [9]. e 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 G and each server's private key contains only one element in group G. 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  U K e y E x t K G C U K e y E x t U se r S K e y E x t K G C S K e y E x t S e r v e r U K e y G e n S K e y G e n DS-IBE-AET construction sends different authorization tokens of the same size of 2ξ G 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 G and one element in Z q . 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 G for comparing a pair of ciphertexts.

Conclusion
is 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
e authors declare that they have no conflicts of interest.   Security and Communication Networks 11