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

Authors: Meng Zhao; Yong Ding
Journal: Security and Communication Networks
 (2022)

---

## 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.


---

## Body

## 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.


## 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

SupposeG=<g> and GT are two cyclic groups of prime order q. The mapping e^:G×G⟶GT is a bilinear pairing if the following conditions are satisfied:


#### 2.1.1. Bilinearity

For anyg1,g2∈RG and α,β∈Rℤq∗,(1)e^g1α,g2β=e^g1,g2αβ.


#### 2.1.2. Non-Degeneracy

There existsg1,g2∈G such that,(2)e^g1,g2≠1.


#### 2.1.3. Efficiency

Forg1,g2∈RG, there exists an efficient algorithm to compute e^g1,g2.


### 2.2. Complexity Assumptions

The security of our DS-IBE-AET construction relies on the following complexity assumptions.CDH assumption. SupposeG=<g> is a cyclic group of prime order q. Given a tuple g,ga,gb where a,b∈Rℤq∗, no probabilistic polynomial-time algorithm A can compute gab with nonnegligible probability.CBDH assumption. SupposeG=<g> and GT are two cyclic groups of prime order q and satisfy bilinear pairing e^:G×G⟶GT. Given a tuple g,ga,gb,gc where a,b,c∈Rℤq∗, no probabilistic polynomial-time algorithm A can compute e^g,gabc with nonnegligible probability.


## 2.1. Bilinear Groups

SupposeG=<g> and GT are two cyclic groups of prime order q. The mapping e^:G×G⟶GT is a bilinear pairing if the following conditions are satisfied:


### 2.1.1. Bilinearity

For anyg1,g2∈RG and α,β∈Rℤq∗,(1)e^g1α,g2β=e^g1,g2αβ.


### 2.1.2. Non-Degeneracy

There existsg1,g2∈G such that,(2)e^g1,g2≠1.


### 2.1.3. Efficiency

Forg1,g2∈RG, there exists an efficient algorithm to compute e^g1,g2.


## 2.1.1. Bilinearity

For anyg1,g2∈RG and α,β∈Rℤq∗,(1)e^g1α,g2β=e^g1,g2αβ.


## 2.1.2. Non-Degeneracy

There existsg1,g2∈G such that,(2)e^g1,g2≠1.


## 2.1.3. Efficiency

Forg1,g2∈RG, there exists an efficient algorithm to compute e^g1,g2.


## 2.2. Complexity Assumptions

The security of our DS-IBE-AET construction relies on the following complexity assumptions.CDH assumption. SupposeG=<g> is a cyclic group of prime order q. Given a tuple g,ga,gb where a,b∈Rℤq∗, no probabilistic polynomial-time algorithm A can compute gab with nonnegligible probability.CBDH assumption. SupposeG=<g> and GT are two cyclic groups of prime order q and satisfy bilinear pairing e^:G×G⟶GT. Given a tuple g,ga,gb,gc where a,b,c∈Rℤq∗, no probabilistic polynomial-time algorithm A can compute e^g,gabc with nonnegligible probability.


## 3. System Model and Security Requirements

### 3.1. System Model

As shown in Figure1, 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 Sf and back server Sb according to their identities, respectively.Figure 1
A system model of DS-IBE-AET.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 serverSf for storage. The data recipient is able to retrieve ciphertexts from the front server Sf and run the decryption procedure using his/her private key. Also, a data recipient is able to authorize the front server Sf and back server Sb 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 serverSf has huge storage resources for maintaining user data in ciphertext format. Both the front server Sf and back server Sb have powerful computing capabilities for collaboratively performing equality tests on user ciphertexts after being authorized. With the authorizations from users, the front server Sf is able to generate internal results of equality tests on ciphertexts, which are then sent to the back server Sb 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 serverSf and back server Sb cannot be forged by any entity.


#### 3.2.3. Data Privacy against the front Server

The front serverSf 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 serverSb 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 serverSf and back server Sb 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,EqTestf, and EqTestb.


#### 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 mpk and system public parameters param. We denote mpk,param←Setup1δ. Note that param is the implicit input for the following eight procedures.


#### 3.3.2. UKeyExt

On input of the master private keympk and a user identity IDi, the user key extraction procedure, which is run by KGC, generates a private key uski for user IDi. We denote uski←UKeyExtmpk,IDi.


#### 3.3.3. SKeyExt

On input of the master private keympk and the identity Sf of the front server (resp. Sb of the back server), the server key extraction procedure, which is run by KGC, generates a private key sskf for the front server Sf (resp. sskb for the back server Sb). We denote sskf/sskb←SKeyExtmpk,Sf/Sb.


#### 3.3.4. Encrypt

On input of the identityIDi 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 Sf. We denote c←Encrypt(IDi, m).


#### 3.3.5. Decrypt

On input of the private keyuski of the data recipient IDi 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(uski, c).


#### 3.3.6. Authen

On input of the private keyuski of user IDi and the identities (Sf, Sb) of the front server and back server, the authentication token generation procedure, which is carried out by the user IDi, 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 Sf and back server Sb, respectively. We denote t^i,f,t^i,b←Authenuski,Sf,Sb.


#### 3.3.7. DecAuth

On input of the private keysskf of the front server Sf (resp. sskb of the back server Sb) and a ciphertext authentication token t^i,f (resp. t^i,b), the authentication decryption procedure, which is performed by the front server Sf (resp. the back server Sb), outputs a plaintext authentication token τi,f (resp. τi,b) or ⊥ that signifies an error in decryption. We denote τi,f/⊥←DecAuthsskf,t^i,f for the front server Sf and τi,b/⊥←DecAuthsskb,t^i,b for the back server Sb.


#### 3.3.8.EqTestf

On input of the plaintext authentication tokensτi,f and τj,f of two users IDi and IDj, respectively, and their ciphertexts c and c′, the front equality test procedure, which is performed by the front server Sf, outputs an internal result Γ and sends it to the back server Sb. We denote Γ←EqTestfτi,f,τj,f,c,c′.


#### 3.3.9.EqTestb

On input of the plaintext authentication tokensτi,b and τj,b of two users IDi and IDj, respectively, and an internal result Γ, the back equality test procedure, which is performed by the back server Sb, outputs 1 if c and c′ encrypt the same message or 0 otherwise. We denote 1/0←EqTestbτ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)
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 output1.(vi)
For any two ciphertexts that encrypt different messages, which may belong to different users, the front and back equality test procedures collaboratively output0 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 mpk,param←Setup1δ, any private keys uski←UKeyExtmpk,IDi, uskj←UKeyExtmpk,IDj of two users IDi and IDj, any private key of the front server sskf←SKeyExtmpk,Sf, and any private key of the back server sskb←SKeyExtmpk,Sb, the following conditions are satisfied:(i)
The private keyuski can be verified as valid in the verification step by the user IDi.(ii)
The private keysskf can be verified as valid in the verification step by the front server Sf, and the private key sskb can be verified as valid in the verification step by the back server Sb.(iii)
For any messagem, Decryptuski,EncryptIDi,m=m.(iv)
DecAuthsskf,t^i,f=τi,f and DecAuthsskb,t^i,b=τi,b, where t^i,f,t^i,b←Authenuski,Sf,Sb.(v)
For any two messagesm, m′ such that c←Encrypt (IDi, m) and c′←Encrypt (IDi, m′), if m=m′, then EqTestbτi,b,τj,b,Γ  =  1, otherwise PrEqTestbτi,b,τj,b,Γ=0≥1−ε⋅, where Γ←EqTestfτi,f,τj,f,c,c′, τi,f=DecAuthsskf,t^i,f, τi,b=DecAuthsskb,t^i,b, τj,f=DecAuthsskf,t^j,f, τj,b=DecAuthsskb,t^j,b, t^i,f,t^i,b←Authenuski,Sf,Sb, t^j,f,t^j,b←Authenuskj,Sf,Sb, and ε⋅ represents a negligible function.


## 3.1. System Model

As shown in Figure1, 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 Sf and back server Sb according to their identities, respectively.Figure 1
A system model of DS-IBE-AET.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 serverSf for storage. The data recipient is able to retrieve ciphertexts from the front server Sf and run the decryption procedure using his/her private key. Also, a data recipient is able to authorize the front server Sf and back server Sb 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 serverSf has huge storage resources for maintaining user data in ciphertext format. Both the front server Sf and back server Sb have powerful computing capabilities for collaboratively performing equality tests on user ciphertexts after being authorized. With the authorizations from users, the front server Sf is able to generate internal results of equality tests on ciphertexts, which are then sent to the back server Sb 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 serverSf and back server Sb cannot be forged by any entity.


### 3.2.3. Data Privacy against the front Server

The front serverSf 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 serverSb 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 serverSf and back server Sb can only be decrypted by themselves, respectively.


## 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 serverSf and back server Sb cannot be forged by any entity.


## 3.2.3. Data Privacy against the front Server

The front serverSf 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 serverSb 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 serverSf and back server Sb 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,EqTestf, and EqTestb.


### 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 mpk and system public parameters param. We denote mpk,param←Setup1δ. Note that param is the implicit input for the following eight procedures.


### 3.3.2. UKeyExt

On input of the master private keympk and a user identity IDi, the user key extraction procedure, which is run by KGC, generates a private key uski for user IDi. We denote uski←UKeyExtmpk,IDi.


### 3.3.3. SKeyExt

On input of the master private keympk and the identity Sf of the front server (resp. Sb of the back server), the server key extraction procedure, which is run by KGC, generates a private key sskf for the front server Sf (resp. sskb for the back server Sb). We denote sskf/sskb←SKeyExtmpk,Sf/Sb.


### 3.3.4. Encrypt

On input of the identityIDi 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 Sf. We denote c←Encrypt(IDi, m).


### 3.3.5. Decrypt

On input of the private keyuski of the data recipient IDi 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(uski, c).


### 3.3.6. Authen

On input of the private keyuski of user IDi and the identities (Sf, Sb) of the front server and back server, the authentication token generation procedure, which is carried out by the user IDi, 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 Sf and back server Sb, respectively. We denote t^i,f,t^i,b←Authenuski,Sf,Sb.


### 3.3.7. DecAuth

On input of the private keysskf of the front server Sf (resp. sskb of the back server Sb) and a ciphertext authentication token t^i,f (resp. t^i,b), the authentication decryption procedure, which is performed by the front server Sf (resp. the back server Sb), outputs a plaintext authentication token τi,f (resp. τi,b) or ⊥ that signifies an error in decryption. We denote τi,f/⊥←DecAuthsskf,t^i,f for the front server Sf and τi,b/⊥←DecAuthsskb,t^i,b for the back server Sb.


### 3.3.8.EqTestf

On input of the plaintext authentication tokensτi,f and τj,f of two users IDi and IDj, respectively, and their ciphertexts c and c′, the front equality test procedure, which is performed by the front server Sf, outputs an internal result Γ and sends it to the back server Sb. We denote Γ←EqTestfτi,f,τj,f,c,c′.


### 3.3.9.EqTestb

On input of the plaintext authentication tokensτi,b and τj,b of two users IDi and IDj, respectively, and an internal result Γ, the back equality test procedure, which is performed by the back server Sb, outputs 1 if c and c′ encrypt the same message or 0 otherwise. We denote 1/0←EqTestbτ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)
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 output1.(vi)
For any two ciphertexts that encrypt different messages, which may belong to different users, the front and back equality test procedures collaboratively output0 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 mpk,param←Setup1δ, any private keys uski←UKeyExtmpk,IDi, uskj←UKeyExtmpk,IDj of two users IDi and IDj, any private key of the front server sskf←SKeyExtmpk,Sf, and any private key of the back server sskb←SKeyExtmpk,Sb, the following conditions are satisfied:(i)
The private keyuski can be verified as valid in the verification step by the user IDi.(ii)
The private keysskf can be verified as valid in the verification step by the front server Sf, and the private key sskb can be verified as valid in the verification step by the back server Sb.(iii)
For any messagem, Decryptuski,EncryptIDi,m=m.(iv)
DecAuthsskf,t^i,f=τi,f and DecAuthsskb,t^i,b=τi,b, where t^i,f,t^i,b←Authenuski,Sf,Sb.(v)
For any two messagesm, m′ such that c←Encrypt (IDi, m) and c′←Encrypt (IDi, m′), if m=m′, then EqTestbτi,b,τj,b,Γ  =  1, otherwise PrEqTestbτi,b,τj,b,Γ=0≥1−ε⋅, where Γ←EqTestfτi,f,τj,f,c,c′, τi,f=DecAuthsskf,t^i,f, τi,b=DecAuthsskb,t^i,b, τj,f=DecAuthsskf,t^j,f, τj,b=DecAuthsskb,t^j,b, t^i,f,t^i,b←Authenuski,Sf,Sb, t^j,f,t^j,b←Authenuskj,Sf,Sb, and ε⋅ represents a negligible function.


## 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 mpk and system public parameters param. We denote mpk,param←Setup1δ. Note that param is the implicit input for the following eight procedures.


## 3.3.2. UKeyExt

On input of the master private keympk and a user identity IDi, the user key extraction procedure, which is run by KGC, generates a private key uski for user IDi. We denote uski←UKeyExtmpk,IDi.


## 3.3.3. SKeyExt

On input of the master private keympk and the identity Sf of the front server (resp. Sb of the back server), the server key extraction procedure, which is run by KGC, generates a private key sskf for the front server Sf (resp. sskb for the back server Sb). We denote sskf/sskb←SKeyExtmpk,Sf/Sb.


## 3.3.4. Encrypt

On input of the identityIDi 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 Sf. We denote c←Encrypt(IDi, m).


## 3.3.5. Decrypt

On input of the private keyuski of the data recipient IDi 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(uski, c).


## 3.3.6. Authen

On input of the private keyuski of user IDi and the identities (Sf, Sb) of the front server and back server, the authentication token generation procedure, which is carried out by the user IDi, 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 Sf and back server Sb, respectively. We denote t^i,f,t^i,b←Authenuski,Sf,Sb.


## 3.3.7. DecAuth

On input of the private keysskf of the front server Sf (resp. sskb of the back server Sb) and a ciphertext authentication token t^i,f (resp. t^i,b), the authentication decryption procedure, which is performed by the front server Sf (resp. the back server Sb), outputs a plaintext authentication token τi,f (resp. τi,b) or ⊥ that signifies an error in decryption. We denote τi,f/⊥←DecAuthsskf,t^i,f for the front server Sf and τi,b/⊥←DecAuthsskb,t^i,b for the back server Sb.


## 3.3.8.EqTestf

On input of the plaintext authentication tokensτi,f and τj,f of two users IDi and IDj, respectively, and their ciphertexts c and c′, the front equality test procedure, which is performed by the front server Sf, outputs an internal result Γ and sends it to the back server Sb. We denote Γ←EqTestfτi,f,τj,f,c,c′.


## 3.3.9.EqTestb

On input of the plaintext authentication tokensτi,b and τj,b of two users IDi and IDj, respectively, and an internal result Γ, the back equality test procedure, which is performed by the back server Sb, outputs 1 if c and c′ encrypt the same message or 0 otherwise. We denote 1/0←EqTestbτ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)
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 output1.(vi)
For any two ciphertexts that encrypt different messages, which may belong to different users, the front and back equality test procedures collaboratively output0 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 mpk,param←Setup1δ, any private keys uski←UKeyExtmpk,IDi, uskj←UKeyExtmpk,IDj of two users IDi and IDj, any private key of the front server sskf←SKeyExtmpk,Sf, and any private key of the back server sskb←SKeyExtmpk,Sb, the following conditions are satisfied:(i)
The private keyuski can be verified as valid in the verification step by the user IDi.(ii)
The private keysskf can be verified as valid in the verification step by the front server Sf, and the private key sskb can be verified as valid in the verification step by the back server Sb.(iii)
For any messagem, Decryptuski,EncryptIDi,m=m.(iv)
DecAuthsskf,t^i,f=τi,f and DecAuthsskb,t^i,b=τi,b, where t^i,f,t^i,b←Authenuski,Sf,Sb.(v)
For any two messagesm, m′ such that c←Encrypt (IDi, m) and c′←Encrypt (IDi, m′), if m=m′, then EqTestbτi,b,τj,b,Γ  =  1, otherwise PrEqTestbτi,b,τj,b,Γ=0≥1−ε⋅, where Γ←EqTestfτi,f,τj,f,c,c′, τi,f=DecAuthsskf,t^i,f, τi,b=DecAuthsskb,t^i,b, τj,f=DecAuthsskf,t^j,f, τj,b=DecAuthsskb,t^j,b, t^i,f,t^i,b←Authenuski,Sf,Sb, t^j,f,t^j,b←Authenuskj,Sf,Sb, 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 Figure2, and the frequently used symbols are summarized in Table 1.Figure 2
A running process of the proposed DS-IBE-AET construction.Table 1
Notations.
SymbolMeaningδSecurity parameterG, GTCyclic groups of prime orderq satisfying bilinear pairing e^:G×G⟶GTH1, H2, H3, H4Cryptographic hash functionsgA generator ofGmpk=d1,d2,d3The master private keyparamThe public parameteruski=uski,1,uski,2,uski,3Private key of userIDisskf, sskbPrivate keys ofSf and Sbc=c1,c2,c3Ciphertext of messagemt^i,f=t0,t1, t^i,b=t0,t2Ciphertext authentication tokens of userIDi for Sf and Sbτi,f′τi,bPlaintext authentication tokens of userIDi for Sf and SbΓ=c1,c1′,ϖInternal test result of equality test


### 4.1. System Setup

Given a security parameterδ, KGC chooses cyclic groups G=<g> and GT satisfying bilinear mapping e^:G×G⟶GT, where groups G and GT have prime order q. KGC selects four cryptographic hash functions H1:0,1∗⟶G, H2:0,1ξm⟶G, H3:GT⟶G and H4:GT×G⟶0,1ξG+logq, where ξG and ξm, respectively, denote the element size in group G and message space. Also, KGC picks three random elements d1,d2,d3∈ℤq∗ and computes the following: (3)V1=gd1,V2=gd2,V3=gd3.At last, KGC keeps the master private keympk=d1,d2,d3 secret and publishes the public parameter param=δ,G,GT,q,e^,g,H1,H2,H3,H4,V1,V2,V3.


### 4.2. User Key Extraction

Given the identity of userIDi, KGC generates the private key uski=uski,1,uski,2,uski,3 as follows:(4)uski,1=H1IDid1,uski,2=H1IDid2,uski,3=H1IDid3.The private keyuski is sent to the user IDi via secure channel. Note that the user IDi is able to validate uski as follows:(5)e^uski,1,g=e^H1IDi,V1,(6)e^uski,2,g=e^H1IDi,V2,(7)e^uski,3,g=e^H1IDi,V3.


### 4.3. Server Key Extraction

Given the identity of the front serverSf, KGC generates the private key as follows:(8)sskf=H1Sfd1,which is sent to the front server Sf via secure channel. Note that the front server Sf is able to validate sskf as follows:(9)e^sskf,g=e^H1Sf,V1.Similarly, KGC can generate the private key for the back serverSb as follows:(10)sskb=H1Sbd1,and the back server Sb is able to validate sskb as follows:(11)e^sskb,g=e^H1Sb,V1.


### 4.4. Data Encryption

For a messagem∈0,1ξm, the sender randomly picks an element α∈ℤq∗, and computes the ciphertext c=c1,c2,c3, where(12)c1=ga,c2=H2m⋅H3e^H1IDi,V1α⋅H3e^H1IDi,V2α,c3=m∥α⊕H4e^H1IDi,V3α∥H2m.The ciphertextc is sent to the front server Sf.


### 4.5. Data Decryption

For ciphertextc=c1,c2,c3, the user IDi decrypts it with the private key uski as follows. The user IDicomputes the following:(13)T=c2H3e^uski,1,c1⋅H3e^uski,2,c1,(14)m′∥α′←c3⊕H4e^uski,3,c1∥T.Next, the userIDi checks whether both of the following equalities hold:(15)c1=ga′,(16)T=H2m′.If so,m′ is outputted, otherwise ⊥ is outputted.


### 4.6. Authorization

The userIDi randomly picks an element γ∈ℤq∗ and computes the following:(17)t0=gγt1=uski,1⋅H3e^H1Sf,V1γ,(18)t1=uski,1⋅H3e^H1Sf,V1γ.Then, the encrypted authorization tokenst^i,f=t0,t1 and t^i,b=t0,t2 are sent to the front server Sf and to the back server Sb, respectively.


### 4.7. Token Decryption

Given the encrypted authorization tokent^i,f, the front server Sf computes the following equation:(19)τi,f=t1H3e^sskf,t0.The back serverSb can decrypt the token uski,b in the similar way as follows:(20)τi,b=t2H3e^sskb,t0,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 ciphertextsc=c1,c2,c3 and c′=c1′,c2′,c3′ of two users IDi and IDj, respectively, the front server Sf generates the internal test result Γ=c1,c1′,ϖ with their respective tokens τi,f and τj,f. The front server Sf computes the following equation:(21)θ=c2H3e^τi,f,c1,(22)θ′=c2′H3e^τj,f,c1′,then, it computes(23)ϖ=θθ′,the internal test result Γ=c1,c1′,ϖ is sent to the back server Sb.


### 4.9. Back Server Ciphertext Test

For the internal test resultΓ=c1,c1′,ϖ on the ciphertexts of users IDi and IDj, the back server Sb checks the following equality with the received tokens τi,b and τj,b:(24)ϖ=H3e^τi,b,c1H3e^τj,b,c1′,if it holds, then “1” is outputted, which means the two ciphertexts c and c' of users IDi and IDj 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 elementuski,1 in the private key uski of user IDi, the equality in (1) holds as follows:(25)e^uski,1,g=e^H1IDid1,g=e^H1IDi,V1.
The equalities in (6) and (7) for the other two elements uski,2 and uski,3 can be verified in the similar way.
Second, for the private keysskf for the front server Sf, the equality in (9) holds as follows:(26)e^sskf,g=e^H1IDid1,g=e^H1IDi,V1.
The equality in (11) for the back server Sb can be verified in the similar way.
Third, for the correctness of decryption on user ciphertexts, since(27)T=c2H3e^uski,1,c1⋅H3e^uski,2,c1=H2m⋅H3e^H1IDi,V1α⋅H3e^H1IDi,V2αH3e^H1IDid1,gα⋅H3e^H1IDid2,gα=H2m⋅H3e^H1IDi,V1α⋅e^H1IDi,V2αH3e^H1IDid1,gα⋅H3e^H1IDid2,gα=H2m.
we have(28)m′‖α′=c3⊕H4e^uski,3,c1‖T=m‖α⊕H4e^H1IDi,V3α‖H2m⊕H4e^H1IDid3,gα‖H2mb=m‖α⊕H4e^H1IDi,gd3α‖H2m⊕H4e^H1IDid3,gα‖H2m=m‖α,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(29)τi,f=t1H3e^sskf,t0=uski,1⋅H3e^H1Sf,V1γH3e^H1Sfd1,gγ=uski,1⋅H3e^H1Sf,gd1γH3e^H1Sfd1,gγ=uski,1.τi,b=t2H3e^sskb,t0=uski,b⋅H3e^H1Sb,V1γH3e^H1Sbd1,gγ=uski,b⋅H3e^H1Sb,gd1γH3e^H1Sbd1,gγ=uski,2.
Thus, the tokens for the front serverSf and back server Sb can be correctly decrypted as in (19) and (20).
Five, for an authorized equality test on ciphertexts, since(30)θ=c3H3e^τi,1,c1=H2m⋅H3e^H1IDi,V1α⋅H3e^H1IDi,V2αH3e^H1IDid1,gα=H2m⋅H3e^H1IDi,gd1α⋅H3e^H1IDi,V2αH3e^H1IDid1,gα=H2m⋅H3e^H1IDi,V2α,θ′=c2′H3e^τj,1,c1′,=H2m′⋅H3e^H1IDj,V1α′⋅H3e^H1IDj,V2α′H3e^H1IDjd1,gα′=H2m′⋅H3e^H1IDj,gd1α′⋅H3e^H1IDj,V2α′H3e^H1IDjd1,gα′=H2m′⋅H3e^H1IDj,V2α′.we have(31)ϖ=θθ′=H2m⋅H3e^H1IDi,V2αH2m′⋅H3e^H1IDj,V2α′=H2m⋅H3e^H1IDi,gd2αH2m′⋅H3e^H1IDj,gd2α′=H2m⋅H3e^H1IDid2,gαH2m′⋅H3e^H1IDjd2,gα′=H2m⋅H3e^uski,2,c1H2m′⋅H3e^uskj,2,c1′⇔m=m′H3e^uski,2,c1H3e^uskj,2,c1′.
It can be seen that if the messagesm and m' are the same, then the equality in (24) holds.
Therefore, the proposed DS-IBE-AET construction in bilinear groups is sound.


## 4.1. System Setup

Given a security parameterδ, KGC chooses cyclic groups G=<g> and GT satisfying bilinear mapping e^:G×G⟶GT, where groups G and GT have prime order q. KGC selects four cryptographic hash functions H1:0,1∗⟶G, H2:0,1ξm⟶G, H3:GT⟶G and H4:GT×G⟶0,1ξG+logq, where ξG and ξm, respectively, denote the element size in group G and message space. Also, KGC picks three random elements d1,d2,d3∈ℤq∗ and computes the following: (3)V1=gd1,V2=gd2,V3=gd3.At last, KGC keeps the master private keympk=d1,d2,d3 secret and publishes the public parameter param=δ,G,GT,q,e^,g,H1,H2,H3,H4,V1,V2,V3.


## 4.2. User Key Extraction

Given the identity of userIDi, KGC generates the private key uski=uski,1,uski,2,uski,3 as follows:(4)uski,1=H1IDid1,uski,2=H1IDid2,uski,3=H1IDid3.The private keyuski is sent to the user IDi via secure channel. Note that the user IDi is able to validate uski as follows:(5)e^uski,1,g=e^H1IDi,V1,(6)e^uski,2,g=e^H1IDi,V2,(7)e^uski,3,g=e^H1IDi,V3.


## 4.3. Server Key Extraction

Given the identity of the front serverSf, KGC generates the private key as follows:(8)sskf=H1Sfd1,which is sent to the front server Sf via secure channel. Note that the front server Sf is able to validate sskf as follows:(9)e^sskf,g=e^H1Sf,V1.Similarly, KGC can generate the private key for the back serverSb as follows:(10)sskb=H1Sbd1,and the back server Sb is able to validate sskb as follows:(11)e^sskb,g=e^H1Sb,V1.


## 4.4. Data Encryption

For a messagem∈0,1ξm, the sender randomly picks an element α∈ℤq∗, and computes the ciphertext c=c1,c2,c3, where(12)c1=ga,c2=H2m⋅H3e^H1IDi,V1α⋅H3e^H1IDi,V2α,c3=m∥α⊕H4e^H1IDi,V3α∥H2m.The ciphertextc is sent to the front server Sf.


## 4.5. Data Decryption

For ciphertextc=c1,c2,c3, the user IDi decrypts it with the private key uski as follows. The user IDicomputes the following:(13)T=c2H3e^uski,1,c1⋅H3e^uski,2,c1,(14)m′∥α′←c3⊕H4e^uski,3,c1∥T.Next, the userIDi checks whether both of the following equalities hold:(15)c1=ga′,(16)T=H2m′.If so,m′ is outputted, otherwise ⊥ is outputted.


## 4.6. Authorization

The userIDi randomly picks an element γ∈ℤq∗ and computes the following:(17)t0=gγt1=uski,1⋅H3e^H1Sf,V1γ,(18)t1=uski,1⋅H3e^H1Sf,V1γ.Then, the encrypted authorization tokenst^i,f=t0,t1 and t^i,b=t0,t2 are sent to the front server Sf and to the back server Sb, respectively.


## 4.7. Token Decryption

Given the encrypted authorization tokent^i,f, the front server Sf computes the following equation:(19)τi,f=t1H3e^sskf,t0.The back serverSb can decrypt the token uski,b in the similar way as follows:(20)τi,b=t2H3e^sskb,t0,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 ciphertextsc=c1,c2,c3 and c′=c1′,c2′,c3′ of two users IDi and IDj, respectively, the front server Sf generates the internal test result Γ=c1,c1′,ϖ with their respective tokens τi,f and τj,f. The front server Sf computes the following equation:(21)θ=c2H3e^τi,f,c1,(22)θ′=c2′H3e^τj,f,c1′,then, it computes(23)ϖ=θθ′,the internal test result Γ=c1,c1′,ϖ is sent to the back server Sb.


## 4.9. Back Server Ciphertext Test

For the internal test resultΓ=c1,c1′,ϖ on the ciphertexts of users IDi and IDj, the back server Sb checks the following equality with the received tokens τi,b and τj,b:(24)ϖ=H3e^τi,b,c1H3e^τj,b,c1′,if it holds, then “1” is outputted, which means the two ciphertexts c and c' of users IDi and IDj 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 elementuski,1 in the private key uski of user IDi, the equality in (1) holds as follows:(25)e^uski,1,g=e^H1IDid1,g=e^H1IDi,V1.
The equalities in (6) and (7) for the other two elements uski,2 and uski,3 can be verified in the similar way.
Second, for the private keysskf for the front server Sf, the equality in (9) holds as follows:(26)e^sskf,g=e^H1IDid1,g=e^H1IDi,V1.
The equality in (11) for the back server Sb can be verified in the similar way.
Third, for the correctness of decryption on user ciphertexts, since(27)T=c2H3e^uski,1,c1⋅H3e^uski,2,c1=H2m⋅H3e^H1IDi,V1α⋅H3e^H1IDi,V2αH3e^H1IDid1,gα⋅H3e^H1IDid2,gα=H2m⋅H3e^H1IDi,V1α⋅e^H1IDi,V2αH3e^H1IDid1,gα⋅H3e^H1IDid2,gα=H2m.
we have(28)m′‖α′=c3⊕H4e^uski,3,c1‖T=m‖α⊕H4e^H1IDi,V3α‖H2m⊕H4e^H1IDid3,gα‖H2mb=m‖α⊕H4e^H1IDi,gd3α‖H2m⊕H4e^H1IDid3,gα‖H2m=m‖α,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(29)τi,f=t1H3e^sskf,t0=uski,1⋅H3e^H1Sf,V1γH3e^H1Sfd1,gγ=uski,1⋅H3e^H1Sf,gd1γH3e^H1Sfd1,gγ=uski,1.τi,b=t2H3e^sskb,t0=uski,b⋅H3e^H1Sb,V1γH3e^H1Sbd1,gγ=uski,b⋅H3e^H1Sb,gd1γH3e^H1Sbd1,gγ=uski,2.
Thus, the tokens for the front serverSf and back server Sb can be correctly decrypted as in (19) and (20).
Five, for an authorized equality test on ciphertexts, since(30)θ=c3H3e^τi,1,c1=H2m⋅H3e^H1IDi,V1α⋅H3e^H1IDi,V2αH3e^H1IDid1,gα=H2m⋅H3e^H1IDi,gd1α⋅H3e^H1IDi,V2αH3e^H1IDid1,gα=H2m⋅H3e^H1IDi,V2α,θ′=c2′H3e^τj,1,c1′,=H2m′⋅H3e^H1IDj,V1α′⋅H3e^H1IDj,V2α′H3e^H1IDjd1,gα′=H2m′⋅H3e^H1IDj,gd1α′⋅H3e^H1IDj,V2α′H3e^H1IDjd1,gα′=H2m′⋅H3e^H1IDj,V2α′.we have(31)ϖ=θθ′=H2m⋅H3e^H1IDi,V2αH2m′⋅H3e^H1IDj,V2α′=H2m⋅H3e^H1IDi,gd2αH2m′⋅H3e^H1IDj,gd2α′=H2m⋅H3e^H1IDid2,gαH2m′⋅H3e^H1IDjd2,gα′=H2m⋅H3e^uski,2,c1H2m′⋅H3e^uskj,2,c1′⇔m=m′H3e^uski,2,c1H3e^uskj,2,c1′.
It can be seen that if the messagesm and m' 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 Sections4.2, the private keys of users are generated by KGC using their private keys d1,d2,d3. 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 Theorem2, the private keys of both servers are generated by KGC using their private keys d1 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 Section4.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 c1,c2 can be seen as an extension of the ciphertext in Boneh and Franklin’s basic IBE scheme [31], Section 4. For the second component c2 of our ciphertext, two public parameters V1 and V2 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 gα is used in producing c2 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 τi,1 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Γ=c1,c1',ϖ 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 c2 in ciphertext of Lee et al.'s scheme [30], but in an identity-based setting [31]. That is, the pairs c1,γ and c1',γ′ have a similar form of c1,c2 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 t0 is used to construct two encrypted authorization tokens t^i,f=t0,t1 and t^i,b=t0,t2 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 ℓ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.Table 2
Comparison of computing costs.
ProcedureOur DS-IBE-AET constructionZhao et al.s construction [9]UKeyExtKGC3ℓE + 3 ℓH—User6ℓP + 3 ℓH3ℓESKeyExtKGC1ℓE + 1 ℓH—Server2ℓP + 1 ℓH2ℓEEncrypt2ℓE + 3 ℓP + 4 ℓH4ℓE + 2 ℓP + 3 ℓHDecrypt1ℓE + 3 ℓP + 3 ℓH4ℓE + 2 ℓP + 3 ℓHAuthen2ℓE + 2 ℓP + 2 ℓH2ℓE + 1 ℓPDecAuthDecryption1ℓP + 1 ℓH1ℓE + 1 ℓPVerification2ℓP + 1 ℓH1ℓEEqTestf2ℓP + 2 ℓH4ℓE + 2 ℓP + 2 ℓHEqTestb2ℓP + 2 ℓH4ℓE + 2 ℓP + 2 ℓHSince 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 is3 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 groupGT 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 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 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 elementt0. Thus, the computing cost for generating t0 can be shared by two tokens. Also, the exponentiation operation of V1γ can be reused in producing both t1 and t2.As shown in (17) and (18), the generation of t1 and t2, 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. The 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 logq=512. The exact execution times of three resource-intensive cryptographic operations are shown in Table 3.Table 3
Execution time of cryptographic operations.
Cryptographic operationComputing time (ms)Bilinear pairing4.211Exponentiation in groupG1.709Map-to-point hash function4.406The 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.Figure 3
Performance of private key extraction procedures in both schemes.The performance of other procedures is depicted in Figure4, 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].Figure 4
Performance of each procedure in our DS-IBE-AET scheme.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 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.Table 4
Comparison of communication costs.
Our DS-IBE-AET schemeZhao et al.‘s scheme [9]User private key3ξG—Server private keyξG—Ciphertext2ξG + ξm + logq2ξG + ξm + logqAuthorization4ξG2ξG + 2 logqInternal test result3ξG3ξGFor 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 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 ℤ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.


## 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 Sections4.2, the private keys of users are generated by KGC using their private keys d1,d2,d3. 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 Theorem2, the private keys of both servers are generated by KGC using their private keys d1 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 Section4.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 c1,c2 can be seen as an extension of the ciphertext in Boneh and Franklin’s basic IBE scheme [31], Section 4. For the second component c2 of our ciphertext, two public parameters V1 and V2 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 gα is used in producing c2 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 τi,1 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Γ=c1,c1',ϖ 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 c2 in ciphertext of Lee et al.'s scheme [30], but in an identity-based setting [31]. That is, the pairs c1,γ and c1',γ′ have a similar form of c1,c2 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 t0 is used to construct two encrypted authorization tokens t^i,f=t0,t1 and t^i,b=t0,t2 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 ℓ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.Table 2
Comparison of computing costs.
ProcedureOur DS-IBE-AET constructionZhao et al.s construction [9]UKeyExtKGC3ℓE + 3 ℓH—User6ℓP + 3 ℓH3ℓESKeyExtKGC1ℓE + 1 ℓH—Server2ℓP + 1 ℓH2ℓEEncrypt2ℓE + 3 ℓP + 4 ℓH4ℓE + 2 ℓP + 3 ℓHDecrypt1ℓE + 3 ℓP + 3 ℓH4ℓE + 2 ℓP + 3 ℓHAuthen2ℓE + 2 ℓP + 2 ℓH2ℓE + 1 ℓPDecAuthDecryption1ℓP + 1 ℓH1ℓE + 1 ℓPVerification2ℓP + 1 ℓH1ℓEEqTestf2ℓP + 2 ℓH4ℓE + 2 ℓP + 2 ℓHEqTestb2ℓP + 2 ℓH4ℓE + 2 ℓP + 2 ℓHSince 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 is3 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 groupGT 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 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 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 elementt0. Thus, the computing cost for generating t0 can be shared by two tokens. Also, the exponentiation operation of V1γ can be reused in producing both t1 and t2.As shown in (17) and (18), the generation of t1 and t2, 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. The 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 logq=512. The exact execution times of three resource-intensive cryptographic operations are shown in Table 3.Table 3
Execution time of cryptographic operations.
Cryptographic operationComputing time (ms)Bilinear pairing4.211Exponentiation in groupG1.709Map-to-point hash function4.406The 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.Figure 3
Performance of private key extraction procedures in both schemes.The performance of other procedures is depicted in Figure4, 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].Figure 4
Performance of each procedure in our DS-IBE-AET scheme.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 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.Table 4
Comparison of communication costs.
Our DS-IBE-AET schemeZhao et al.‘s scheme [9]User private key3ξG—Server private keyξG—Ciphertext2ξG + ξm + logq2ξG + ξm + logqAuthorization4ξG2ξG + 2 logqInternal test result3ξG3ξGFor 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 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 ℤ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.


## 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.



---

*Source: 4905763-2022-10-11.xml*