1.   Introduction

It is convenient for people to outsource gradually increasing amounts of data on their local devices to cloud servers with powerful storage and computing abilities. To protect the privacy of sensitive data, people prefer to encrypt their data before outsourcing them. As a consequence, cloud servers cannot directly perform computations on outsourced data as on raw data, while it will be meaningless if the outsourced data can only be downloaded and locally processed by the outsourcers themselves. For this challenge, a sequence of techniques was proposed, such as searchable encryption (SE)^[1] supporting search on encrypted data, fully homomorphic encryption (FHE)^[2] supporting addition and multiplication on encrypted data, and public-key encryption with equality test (PKEET)^[3] supporting equality tests on encrypted data. In particular, PKEET can check whether the underlying messages of ciphertexts are equal or not without decryption, even those that are encrypted with different public keys. This property enables PKEET to be technically useful in many scenarios, such as friend matching. For those people who want to make friends and dislike showing their interests on the Internet, they can upload their encrypted interests to the website. The website can then perform PKEET on encrypted interests and recommend people to those with the same interests.

Due to the certificate management problem in public-key infrastructure, Ma^[4] extended PKEET to Identity-Based Encryption (IBEET). The existing IBEET schemes inherit the system model proposed by Ma^[4]. As shown in Fig.1, there are three kinds of entities, the private key generator (PKG), cloud servers, and authorizers $U_1,\; U_2 ,\;\ldots,\; U_n$. In IBEET, the PKG generates private keys for all authorizers. An authorizer first sends his/her identity $ID$ to the PKG. After verifying the validity of $ID$, the PKG generates and returns the corresponding private key $d_{ID}$ to the authorizer. The authorizer can encrypt his/her data with $ID$ and upload it to the cloud server. Note that, due to the property of IBE, authorizers can encrypt their data before requesting a private key from the PKG. Once an authorizer tends to obtain test results on his/her ciphertexts, he/she performs the following steps. Without loss of generality, we assume the authorizer $U_1$ with identity $ID$ tries to obtain the test results. $U_1$ sends an authorization submission to the PKG that can then construct a trapdoor $td_{ID}$ for the cloud server. We also notice that the trapdoor is generated by the PKG in IBEET, instead of by the authorizer as that in PKEET. With the received trapdoor $td_{ID}$ and test order from $U_1$, the cloud server performs equality tests on ciphertexts of $U_1$ and other authorized ciphertexts. Finally, it sends the test results $1/0$ to $U_1$, where 1 denotes that the underlying messages of the ciphertexts are equal and 0 else.

Figure  1.  System model of IBEET in cloud computing. $d_{ID}$: the private key of the authorizer $U_1$ with $ID$. $td_{ID}$: the trapdoor of the authorizer $U_1$ with $ID$.

下载: 全尺寸图片 幻灯片

However, we claim that the above IBEET system model suffers from the illegal trapdoor sharing problem caused by the inherited key escrow problem of IBE. As we emphasized in the last paragraph, in IBEET, trapdoors are generated and distributed by the PKG with the master secret key and then sent to the authorized cloud servers. That is, the PKG has full control over trapdoors. In practice, the PKG could be a not-fully-trusted company, which means they may freely generate trapdoors of any authorizer and even illegally share or sell them without any risk of being caught in IBEET. Meanwhile, an authorized cloud server may also share its received trapdoor out of economic profits or some other reason. This means once there is a disputed trapdoor, it could be constructed by the PKG or one of the authorized cloud servers, while the existing IBEET schemes cannot tell the real generator. This problem may lead to serious consequences, such as illegal trapdoor sharing for a gene bank. Then we have a challenge that how to identify the real generator of a given disputed trapdoor with convincing evidence such that the suspect can be held accountable in IBEET.

In this paper, we fill this gap in the literature on IBEET. Specifically, our contributions are three fold and summarized as follows.

1) We introduce accountability into IBEET and present a new notion, called IBEET Supporting Accountable Authorization (IBEET-AA). In IBEET-AA, not only the equality of ciphertexts' underlying messages can be checked, but also the real generator of a pirated trapdoor can be traced among the PKG and suspected testers. As shown in Fig.2, there is a third party in IBEET-AA compared with IBEET. The additional third party can be considered as the court in practice such that the real generator of the pirated trapdoor can be held accountable. Differing from that in traditional IBEET, the trapdoors in IBEET-AA are interactively generated by the PKG and authorized cloud servers such that the PKG has no knowledge of which trapdoor the authorized cloud server finally obtains, although trapdoors are generated with the help of PKG. This prevents the PKG from framing the tester by sharing the same trapdoor. Also, the cloud server identity $ID_t$ is inserted in the trapdoor to enable possible tracing, which enables the related tester to be distinguished from all the authorized testers.

Figure  2.  System model of IBEET-AA in cloud computing. $ID_t$: the identity of the tester. $td_{ID, \ ID_t}$: the trapdoor of the authorizer $U_1$ with $ID$ for the tester with $ID_t$. $td_{ID, \ *}, td_{ID, \ *}'$: the to-be-traced trapdoor related to the authorizer $U_1$ with $ID$ and an unknown tester with identity $*$.

下载: 全尺寸图片 幻灯片

2) We give the formalized definition and security models of IBEET-AA. In traditional IBEET, there are two types of adversaries against message confidentiality, and the indistinguishability (IND) and one-way (OW) security models^[4] are designed to prevent their attacks, respectively. In IBEET, due to the additional tracing function, we depict three more types of adversaries to protect tracing security against dishonest authorizers, the PKG, and testers, respectively. The security against dishonest authorizers ensures that an authorizer with $ID$ cannot forge a trapdoor with which the ciphertexts encrypted with $ID$ can be tested. The security against dishonest PKG prevents the PKG from framing a tester by generating a trapdoor with which the third party will determine the related tester as its generator. The security against dishonest testers prevents the tester from framing the PKG.

3) Similar to the accountability in IBE, we split IBEET-AA into black-box and white-box IBEET-AA according to whether the scheme can further trace a decoder box or not, instead of only the well-formed trapdoors. We instantiate the IBEET-AA and propose a white-box IBEET-AA construction based on Gentry’s IBE scheme^[5]. Compared with Gentry’s scheme, our scheme has the same key size and just one more element in the ciphertext. We give the formal proof of the proposed IBEET-AA scheme under five security models to prove its message confidentiality and security against dishonest authorizers, the PKG, and testers. For simplicity, we apply the IND-CPA version of Gentry’s IBE scheme, but our scheme can be extended to CCA security by applying the technique of [5].

2.   Related Work

PKEET. The notion of PKEET was proposed by Yang et al.^[3] along with the first related construction in which everyone can play the role of the tester. Tang introduced the authorization into PKEET^[6] and formalized the IND and OW security models against the unauthorized and authorized adversary for message confidentiality in PKEET, respectively^[7]. Subsequent efforts have mainly been devoted to kinds of authorizations on the testing scope to satisfy different privacy requirements^{[7, 8]}, improving security^[9-11], extensions to other primitives^[12-14], and flexible functions^[15-17].

IBEET. To simplify the complex certificate management in PKEET, Ma^[4] firstly presented the concept of IBEET. Wu et al.^[18] improved the efficiency by reducing the demand for time-consuming hash-to-point operations. To endow flexible authorizations to the participants of IBEET systems, Li et al.^[19] introduced the notion of IBEET supporting flexible authorization (IBEET-FA), which is a variant of PKEET-FA^[20] in the identity-based setting. Lee et al.^[21] presented a semi-generic method for IBEET and Lin et al.^[22] improved the efficiency and gave a generic IBEET construction. Also, Lee et al.^[23] gave a generic IBEET construction that is secure in the standard model, while most previous schemes are secure with the random oracle model.

3.   Preliminaries

3.1   Definition of IBEET

We recall the definition of IBEET as below^[4].

${\sf Setup}$($1^{\lambda}$). Taking as input a security parameter $1^{\lambda}$, it generates the master public/secret key pair $(mpk,\, msk)$, where $mpk$ naturally contains the message space $\mathcal{M}$ and the identity space $\mathcal{ID}$, denoted by $(mpk,\, msk)\leftarrow {\sf Setup}(1^{\lambda})$.

${\sf KeyGen}$($mpk,\, msk,\, ID$). Taking as input an identity $ID\in \mathcal{ID}$, it generates the corresponding private key $d_{ID}$, denoted by $d_{ID}\leftarrow {\sf KeyGen}(mpk,\, msk, \, ID)$. For the same $ID$, it will output the same $d_{ID}$.

${\sf Aut}$($mpk,\, msk,\, ID$). It generates a trapdoor $td_{ID}$ with which any tester can perform equality tests on the ciphertexts encrypted with $ID$, denoted by $td_{ID}\leftarrow {\sf Aut}(mpk,\, msk,\, ID)$.

${\sf Enc}$($mpk,\, ID,\, M$). Taking as input a message $M\in \mathcal{M}$, it generates a ciphertext $CT$, denoted by $CT\leftarrow {\sf Enc}(mpk,\, ID,\, M)$.

${\sf Dec}$($mpk,\, d_{ID},\, CT$). Taking as input the private key $d_{ID}$ of user with $ID$ and a ciphertext $CT$ encrypted with $ID$, it returns a message $M$ or $\bot$, denoted by $M/\bot \leftarrow {\sf Dec}(mpk,\, d_{ID},\, CT)$.

${\sf Test}$($mpk,\, td_{ID_1},\, td_{ID_2},\, CT_1,\, CT_2$). Taking as input two trapdoors $td_{ID_1},\, td_{ID_2}$ and two ciphertexts $CT_1, \, CT_2$ encrypted with $(ID_1,\, M_1),\, (ID_2,\, M_2)$, respectively, it outputs 1 or 0 denoting that $M_1=M_2$ or $M_1\neq M_2$, respectively, denoted by $1/0 \leftarrow {\sf Test}(mpk,$ $td_{ID_1},\, td_{ID_2},\, CT_1,\, CT_2)$.

3.2   Correctness Requirements of IBEET

Obviously, the correctness of IBEET requires decryption and testing correctness.

Decryption Correctness. Given any master key pair $(mpk,\, msk)\leftarrow {\sf Setup}(1^{\lambda})$, identity $ID\in \mathcal{ID}$, private key $d_{ID}\leftarrow {\sf KeyGen}(mpk,\, msk,\, ID)$, message $M\in \mathcal{M}$, and ciphertext $CT\leftarrow {\sf Enc}(mpk,\, ID,\, M)$, we have

Testing Correctness. Given any master key pair $(mpk,\, msk)\leftarrow {\sf Setup}(1^{\lambda})$, identities $ID_i\in \mathcal{M}$, trapdoors $td_{ID_i}\leftarrow {\sf Aut}(mpk,\, msk,\, ID_i)$, messages $M_i\in \mathcal{M}$, and ciphertexts $CT_i\leftarrow {\sf Enc}(mpk,\, ID_i,\, M_i)$, $i\in \{1,\,2\}$,

● if $M_1=M_2$, we have

● if $M_1\neq M_2$, we have

3.3   Security Model of IBEET

As traditional PKEET schemes^[7], there are two types of adversaries against message confidentiality in IBEET.

1) The type-1 adversary is not allowed to issue the trapdoor query related to the challenge identity $ID^*$ that is encrypted in the challenge ciphertext $CT^*$, which means it cannot perform equality tests on $CT^*$. For the type-1 adversary $\mathcal{A}=( \mathcal{A}_1,\, \mathcal{A}_2)$, the IND-ID-ATK security model is defined as Fig.3, where ATK could be CCA, CCA1, and CPA.

Figure  3.  IND-ID-ATK game. $M_0^*,\, M_1^*$: two messages chosen by the adversary $\mathcal{A}$. $\delta$: information known by the adversary $\mathcal{A}$ when it accesses the $\mathcal{O}_1$ oracle. $b$: a random bit chosen from $\{0,\, 1\}$. $b'$: the bit output by the adversary $\mathcal{A}$.

下载: 全尺寸图片 幻灯片

As defined, the adversary can run $\mathcal{A}_1$ and $\mathcal{A}_2$ to access the $\mathcal{O}_1$ and $\mathcal{O}_2$ oracle, respectively. We have that

● if ATK=CCA, $\mathcal{O}_1,\, \mathcal{O}_2=\{ \mathcal{O}_k,\, \mathcal{O}_d,\, \mathcal{O}_t\}$,

● if ATK=CCA1, $\mathcal{O}_1=\{ \mathcal{O}_k,\, \mathcal{O}_d,\, \mathcal{O}_t\}, \, \mathcal{O}_2=\{ \mathcal{O}_k, \mathcal{O}_t\}$,

● if ATK=CPA, $\mathcal{O}_1,\, \mathcal{O}_2=\{ \mathcal{O}_k,\, \mathcal{O}_t\}$,

where we define $\mathcal{O}_k$ as the private key oracle with input $ID$, $\mathcal{O}_d$ as the decryption oracle with input $(ID,\, CT)$, and $\mathcal{O}_t$ as the trapdoor oracle with input $ID$. In particular, $ID^*$ cannot be queried to $\mathcal{O}_k$ and $\mathcal{O}_t$, and $(ID^*,\, CT^*)$ cannot be queried to $\mathcal{O}_d$. The advantage of $\mathcal{A}$ in winning the above game is defined as

2) The type-2 adversary is allowed to query the trapdoor related to $ID^*$. For the type-2 adversary $\mathcal{A}$, the OW-ID-ATK security model is defined as Fig.4, where ATK could be CCA and CPA.

Figure  4.  OW-ID-ATK game. $\delta$: information known by the adversary $\mathcal{A}$ when it accesses the $\mathcal{O}$ oracle. $M^*$: the challenge message chosen from the message space $\mathcal{M}$. $M'$: the message output by the adversary $\mathcal{A}$.

下载: 全尺寸图片 幻灯片

In the game, the adversary can access the oracle $\mathcal{O}$, and we have that

● if ATK=CCA, $\mathcal{O}=\{ \mathcal{O}_k,\, \mathcal{O}_d,\, \mathcal{O}_t\}$,

● if ATK=CPA, $\mathcal{O}=\{ \mathcal{O}_k,\, \mathcal{O}_t\}$.

We still define oracles $\mathcal{O}_k,\, \mathcal{O}_d,\, \mathcal{O}_t$ with the restriction that $ID^*$ cannot be queried to $\mathcal{O}_k$ and $(ID^*,\, CT^*)$ cannot be queried to $\mathcal{O}_d$. The advantage of $\mathcal{A}$ in winning the above game is defined as

3.4   Assumptions

$q$-SDH Assumption^[24]. Let $\mathbb{G}$ be a cyclic group of prime order $p$, $g$ be a generator of $\mathbb{G}$, and $a\in \mathbb{Z}_p$ be a randomly chosen number. Given $g,\, g^a,\, g^{a^2},\, \ldots,\, g^{a^q}\in \mathbb{G}$, no probabilistic polynomial-time algorithm can compute the tuple $(s,\, g^{\tfrac{1}{a+s}})\in \mathbb{Z}_p \times \mathbb{G}$ for any $s\in \mathbb{Z}_p$ with non-negligible advantage.

DL Assumption. Let $\mathbb{G}$ be a cyclic group of prime order $p$, $g$ be a generator of $\mathbb{G}$, and $a\in \mathbb{Z}_p$ be a randomly chosen number. Given $g,\, g^a\in \mathbb{G}$, no probabilistic polynomial-time algorithm can compute $a$ with non-negligible advantage.

$q$-DABDHE Assumption^[5]. Let $\mathbb{G},\, \mathbb{G}_T$ be cyclic groups of prime order $p$, $e: \mathbb{G}\times \mathbb{G}\rightarrow \mathbb{G}_T$ be a pairing, g and h be generators of $\mathbb{G}$, and $a,\, q \in \mathbb{Z}_p$ be randomly chosen numbers. Given $g,\, g^a,\, g^{a^2},\, \ldots,\, g^{a^q},\, h, h^{a^{q+2}}\in$ $\mathbb{G}, Z\in \mathbb{G}_T$, no probabilistic polynomial-time algorithm can determine whether $Z=e(g,\, h)^{a^{q+1}}$ holds or not with non-negligible advantage.

4.   IBEET-AA: Identity-Based Encryption with Equality Test Supporting Accountable Authorization

To relieve the illegal trapdoor sharing problem caused by the key escrow problem in IBEET when being applied in cloud computing, we introduce the notion of accountable authorization into IBEET and present a new notion, called IBEET Supporting Accountable Authorization (IBEET-AA). Using IBEET-AA, the real generator of pirated trapdoors can be extracted to be held accountable. This deters the suspectors from illegally sharing their trapdoors with others.

4.1   Definition of IBEET-AA

As shown in Fig.2, in IBEET-AA, an authorization protocol, instead of an algorithm as that in traditional IBEET schemes, is designed to generate trapdoors for authorized cloud servers. The PKG interacts with the cloud server to construct the trapdoor, and only the tester knows the final exact trapdoor while the PKG does not. An additional tracing algorithm is constructed to trace the generator of a disputed trapdoor. Of particular importance is that we also divide IBEET-AA into different types as that in other accountable primitives^[25]. According to whether the tracing algorithm can only trace a well-formed pirated trapdoor or can further trace a decoder box, IBEET-AA is classified into white-box and black-box IBEET-AA. An IBEET-AA scheme consists of the following seven algorithms.

1) $\sf {AA.Setup}$($1^{\lambda}$). The same as ${\sf Setup}$, it is denoted by $(mpk,\, msk)\leftarrow {\sf AA.Setup}(1^{\lambda})$.

2) $\sf {AA.KeyGen}$($mpk,\, msk,\, ID$). The same as ${\sf KeyGen}$, it is denoted by $d_{ID}\leftarrow {\sf AA.KeyGen}(mpk,\, msk,\, ID)$.

3) $\sf {AA.Aut}$($mpk,\, msk,\, ID,\, ID_t$). This is an authorization protocol run by the PKG and the to-be-authorized tester with $ID_t$. Finally, the tester obtains the trapdoor $td_{ID, \, ID_t}$, denoted by $td_{ID,\, ID_t}\leftarrow {\sf AA.Aut}$ $(mpk, msk,\, ID,\, ID_t)$. Note that, the PKG does not know which trapdoor the tester finally obtains. At any time, any party may abort. For the same $(ID,\, ID_t)$, it will output the same $td_{ID,\, ID_t}$.

4) $\sf {AA.Enc}$($mpk,\, ID,\, M$). The same as ${\sf Enc}$, it is denoted by $CT\leftarrow {\sf AA.Enc}(mpk,\, ID,\, M)$.

5) $\sf {AA.Dec}$($mpk,\, d_{ID},\, CT$). The same as ${\sf Dec}$, it is denoted by $M/\bot \leftarrow {\sf AA.Dec}(mpk,\, CT,\, d_{ID})$.

6) $\sf AA.Test$($mpk, td_{ID_1, ID_t}, td_{ID_2,\ ID_t}, CT_1, CT_2$). Taking as input trapdoors $td_{ID_1,\, ID_t}, td_{ID_2,\, ID_t}$ and two ciphertexts $CT_1,\, CT_2$, where trapdoors are relate to the same tester as $ID_t$ and the ciphertext $CT_i$ is encrypted with $(ID_i,\, M_i)$ for $i\in \{1,2\}$, the testing algorithm outputs 1 or 0 denoting that $M_1=M_2$ or $M_1\neq M_2$, respectively, denoted by $1/0 \leftarrow {\sf AA.Test}(mpk,$ $td_{ID_1,\, ID_t},\, td_{ID_2,\, ID_t},\, CT_1,\, CT_2)$.

7) $\sf AA.Trace$. Given a disputed pirated trapdoor $td_{ID,\, *}'$ with which the ciphertexts encrypted with $ID$ can be tested, the tracing algorithm can extract the real generator by tester tracing and authority tracing as follows.

● $\sf AA.TTrace$($mpk,\, td_{ID,\, *},\, \{ ID_{t,\, i}\}_{1\leqslant i\leqslant n_{ID}}$). Suppose there are $n_{ID}$ testers authorized by $ID$ with corresponding identities as $\{ ID_{t,i}\}_{1\leqslant i\leqslant n_{ID}}$. Taking as input the pirated trapdoor $td_{ID,\, *}'$, the tester tracing algorithm outputs the identity $ID_t$ of related tester, where $ID_t\in \{ID_{t_i}\}_{1\leqslant i\leqslant n_{ID}}$, denoted by $ID_t\leftarrow$ ${\sf AA.TTrace}(mpk,\, td_{ID,*}',\, \{ID_{t,\, i}\}_{1\leqslant i\leqslant n_{ID}})$. We then have that the given disputed trapdoor $td_{ID,\, *}'$ is $td_{ID,\, ID_t}'$.

● $\sf AA.ATrace$($mpk,\, td_{ID,\, ID_t},\, td_{ID,\, ID_t}'$). Taking as input the pirated trapdoor $td_{ID,\, ID_t}'$ and the trapdoor $td_{ID,\, ID_t}$ of the tester with $ID_t$, the authority tracing algorithm outputs T or PKG denoting that the pirated trapdoor is generated by the tester or PKG, respectively, denoted by ${\rm{T/PKG}}\leftarrow {\sf AA.ATrace}(mpk,$ $td_{ID,\, ID_t},\ td_{ID,\, ID_t}')$.

This IBEET-AA scheme is a white-box scheme since the tracing algorithm can only trace a well-formed trapdoor. If the tracing algorithm can further trace a decoder box $D$, it is a black-box IBEET-AA scheme.

4.2   Correctness Requirements of IBEET-AA

The correctness of an IBEET-AA scheme requires decryption correctness, testing correctness, and tracing correctness, where the decryption and testing correctnesses are as those in the traditional IBEET schemes (defined in Subsection 3.1). The additional tracing correctness is defined below.

Tracing Correctness. It is divided into two steps.

1) For any key pair $(mpk,\, msk)\leftarrow {\sf AA.Setup}(1^{\lambda})$, identities $ID_i,\, \{ID_{t,\, i}\}_{1\leqslant i\leqslant n_{ID}}\in \mathcal{ID}$, and trapdoors $td_{ID_i,\, ID_t}'\leftarrow {\sf AA.Aut}(mpk,\, msk,\, ID_i,\, ID_t)$, we have

2) Furthermore, for any $td_{ID,\, ID_t}\leftarrow {\sf Aut}(mpk,\, msk,$ $ID,\, ID_t,\, d_{ID})$,

● if $td_{ID,\, ID_t}'$ is generated by PKG, we have

● if $td_{ID,\, ID_t}'$ is generated by $ID_t$, we have

4.3   Security Models of IBEET-AA

The same as IBEET, there are two types of adversaries in IBEET-AA against message confidentiality. Correspondingly, the IND and OW security models which are the same as those for IBEET (Subsection 3.2), are omitted here. For additional accountability, there are three more types of adversaries acting as a dishonest authorizer, the PKG, and the tester, respectively. Specifically, the security against dishonest authorizers ensures that the pirated trapdoor can only come from the PKG or a related tester. Dishonest PKG security prevents the PKG from framing any tester, which means the PKG cannot generate a trapdoor such that the tracing algorithm will determine the related tester as the generator. Dishonest tester security prevents any tester from framing the PKG. These three securities lay the foundation for the correctness of the tracing algorithm in IBEET-AA.

1) The type-3 adversary $\mathcal{A}$ acts as a malicious authorizer with $ID^*$ who tries to construct a pirated trapdoor $td_{ID^*,\, ID_t^*}'$ for a tester with $ID_t^*$, as defined in Fig.5.

Figure  5.  Dishonest authorizer game.

下载: 全尺寸图片 幻灯片

In the above dishonest authorizer game, $(ID^*,\, ID_t^*)$ is not allowed to be queried to $\mathcal{O}_t$. The advantage $Adv^{\rm{Dishonest\; authorizer}}_{{{\mathrm{IBEET}}{\text{-}}{\mathrm{AA}}},\, \mathcal{A}}(\lambda)$ of $\mathcal{A}$ in winning the above game is defined as

Note that, this type of adversary also covers the type of malicious tester who tries to construct a pirated trapdoor for another tester.

2) The type-4 adversary acts as the malicious PKG who tries to construct a pirated trapdoor $td_{ID^*, \, ID_t^*}'$ for the tester with $ID_t^*$ such that the tracing algorithm will determine the generator of this pirated trapdoor as the related tester with $ID_t^*$, as defined in Fig.6.

Figure  6.  Dishonest PKG game. $ID^*$: the challenge identity of the authorizer chosen by the adversary $\mathcal{A}$.

下载: 全尺寸图片 幻灯片

The advantage $Adv^{\rm{Dishonest\; PKG}}_{{{\mathrm{IBEET}}{\text{-}}{\mathrm{AA}}},\, \mathcal{A}}(1^{\lambda})$ of $\mathcal{A}$ in winning the above game is defined as

3) The type-5 adversary acts as a malicious tester with $ID_t^*$ who tries to frame the PKG by constructing a pirated trapdoor $td_{ID^*,\, ID_t^*}'$ such that the tracing algorithm will output PKG, as defined in Fig.7.

Figure  7.  Dishonest tester game. $ID^*$: the challenge identity of the authorizer chosen by the adversary $\mathcal{A}$.

下载: 全尺寸图片 幻灯片

In the dishonest authorizer game, the advantage $Adv^{\rm{Dishonest\;tester}}_{{{\mathrm{IBEET}}{\text{-}}{\mathrm{AA}}},\, \mathcal{A}}(1^{\lambda})$ of $\mathcal{A}$ in winning the above game is defined as

Definition 1 (Security of IBEET-AA). An IBEET-AA system is secure if all probabilistic polynomial-time adversaries have at most negligible advantage in winning the OW-ID-ATK, IND-ID-ATK, dishonest authorizer, dishonest PKG, and dishonest tester games.

5.   Our IBEET-AA Construction

Based on the Gentry IBE scheme^[5], we propose a specific efficient IBEET-AA construction.

5.1   Scheme Design

For simplicity, we use the IND-CPA secure version of Gentry IBE. Let $\mathbb{G}$ and $\mathbb{G}_T$ be two multiplicative cyclic groups of prime order $p$ and $e: \mathbb{G}\times \mathbb{G} \rightarrow \mathbb{G}_T$ be a bilinear map satisfying $e(g^a,\, g^b) = e(g,\, g)^{ab}$ and $e(g,\, g) \neq 1$ for generators $g\in \mathbb{G}$ and random numbers $a,\, b \in \mathbb{Z}_p$. Let $\mathbb{PG} = ( \mathbb{G},\, \mathbb{G}_T,\, g,\, p,\, e)$ denote a pairing group.

1) $\sf {AA.Setup}$($\lambda$). It chooses a pairing group $\mathbb{PG} = ( \mathbb{G},\, \mathbb{G}_T,\, g,\, p,\, e)$ and cryptographic hash functions $H:\{0,\, 1\}^*\to \mathbb{G},\, H_1: \{0,1\}^*\rightarrow \mathbb{G}_T$, randomly picks $\alpha,\, \beta\in \mathbb{Z}_p$, and computes $h_1=g^\alpha,\, h_2=g^{\beta}$. It then sets the master public/secret key pair $(mpk,\, msk)$ as

2) $\sf {AA.KeyGen}$($mpk,\, msk,\, ID$). It randomly chooses $r\in \mathbb{Z}_p$ and computes the private key $d_{ID}$ of $ID$ as

3) $\sf {AA.Aut}$($mpk,\, msk,\, ID,\, ID_t$). Our authorization protocol is interactively run by the authorizer with $ID$, the PKG, and the to-be-authorized tester with $ID_t$. We depict the flow path of our protocol in Fig.8. Once an authorizer wants to authorize a tester, it first generates a proof to convince the PKG and then the PKG interacts with the tester to construct a trapdoor as below.

Figure  8.  Flow path of authorization protocol.

下载: 全尺寸图片 幻灯片

● Authorizer. The authorizer with private key $d_{ID}=(d_1,\, d_2)$ computes the proof as

and sends $(ID,\, ID_t,\, proof_{ID,\, ID_t})$ to the PKG.

● PKG. After receiving the trapdoor submission $(ID,\, ID_t,\, proof_{ID,\, ID_t})$ from the authorizer with $ID$, the PKG uses the related private key $d_{ID}=(d_1,\, d_2)$ and checks whether the equation

holds or not. If not, it aborts. Otherwise, it interacts with the tester as below.

● Tester. The tester randomly chooses $\hat{r}\in \mathbb{Z}_p$ and computes $R=g^{\hat{r}}$. It runs the zero-knowledge proof (ZKP)^[26] with the PKG as described in Fig.9 to prove that $R=g^{\hat{r}}$. Finally, if the PKG accepts $R=g^{\hat{r}}$, the ZKP succeeds. Otherwise, it fails.

Figure  9.  Zero-knowledge proof of R.

下载: 全尺寸图片 幻灯片

● PKG. If the proof fails, the PKG aborts. Otherwise, it picks a random number $\overline{r}\in \mathbb{Z}_p$ and computes a “partial” trapdoor for $ID_t$ as

The PKG then sends $\overline{td_{ID,\, ID_t}}$ to the tester.

● Tester. With the received $\overline{td_{ID,\, ID_t}}=\left( \overline{td_{ID,\, ID_t}^1}, \right. \left. \overline{td_{ID,\, ID^t}^2}\right)$, the tester checks whether

holds, and aborts if not. Otherwise, it sets the trapdoor as

where

4) $\sf {AA.Enc}$($mpk,\, ID,\, M$). For a message $M\in \mathbb{G}_T$, it randomly chooses $s\in \mathbb{Z}_p$ and computes the ciphertext CT as

5) $\sf {AA.Dec}$($mpk,\, d_{ID},\, CT$). It computes the message as

6) ${\sf AA.Test}$($mpk,\, td_{ID_1,\, ID_t},\, td_{ID_2,\, ID_t},\, CT_1,\, CT_2$). Taking as input trapdoors $td_{ID_i,\, ID_t}= (td_{ID_i,\, ID_t}^1,\, td_{ID_i,\, ID_t}^2)$ and two ciphertext $CT_i=(C_{i,\, 1},\, C_{i,\, 2},\, C_{i,\, 3},\, C_{i,\, 4})$ encrypted with $(ID_i,\, M_i)$ for $i\in \{1,\, 2\}$, the testing algorithm computes

It then checks whether

holds or not. If the equation holds, it outputs 1 denoting that $M_1=M_2$. Otherwise, it outputs 0 denoting that $M_1\neq M_2$.

7) ${\sf AA.Trace}$. If there is a pirated trapdoor $td_{ID,\, *}'$ with which the ciphertexts of the authorizer with $ID$ can be tested, the tracing algorithm can retrieve the real generator from the PKG and related testers. It is divided into two steps, namely tester tracing and authority tracing.

● ${\sf AA.TTrace}$$(mpk,\, td_{ID,\, *}',\, \{ID_{t_i}\}_{1\leqslant i\leqslant n_{ID}})$. This is to trace the tester related to the pirated trapdoor among the authorized testers by the user with $ID$. Suppose there are $n_{ID}$ testers. Given a pirated trapdoor $td_{ID,\, *}'=\left( (td_{ID,\, *}^1)',\, (td_{ID,\, *}^2)' \right)$, it extracts the related tester by checking whether the following equation holds for any tester with $ID_{t_i}$ among all $n_{ID}$ possible candidates:

If none of them holds, it aborts. Otherwise, it outputs $ID_t$ that satisfies the above equation. We then have the pirated trapdoor as $td_{ID,\, ID_t}'=((td_{ID,\, ID_t}^1)', (td_{ID,\, ID_t}^2)')$.

● ${\sf AA.ATrace}$$(mpk,\, td_{ID,\, ID_t},\, td_{ID,\, ID_t}')$. With the cooperation of the tester with $ID_t$, it first checks whether the following equation holds and aborts if not.

Otherwise, if $(td_{ID,\, ID_t})^1=(td_{ID,\, ID_t}')^1$, it outputs T denoting that the pirated trapdoor is generated by the tester, and it outputs PKG if $(td_{ID,\, ID_t})^1\neq (td'_{ID,}$ ${ID_t}')^1$ denoting that the pirated trapdoor is generated by the PKG.

5.2   Correctness Analysis of Our IBEET-AA Scheme

Below, we analyze the correctness of the above scheme.

1) Decryption Correctness. Let $CT=(C_1,\, C_2,\, C_3, C_4)$ be a well-formed ciphertext encrypted with $ID$ and $M$, we have

We have the correct decryption result.

2) Testing Correctness. Given two ciphertexts $CT_i =(C_{i,1},\, C_{i,2},\, C_{i,3},\, C_{i,4})$ encrypted with $M_i$ and $ID_i$ satisfying $M_1=M_2$ and the corresponding trapdoors $td_{ID_i,\, ID_t}=\left( (td_{ID_i,\, ID_t})^1,\, (td_{ID_i,\, ID_t})^2\right)$ for $i\in \{1, 2\}$, we have

If $M_1=M_2$, we will have $H_1(M_1)=H_1(M_2)$, and therefore the testing algorithm will output 1. Otherwise, we have $H_1(M_1)\neq H_1(M_2)$, and the testing algorithm will output 0.

3) Tracing Correctness. As a white-box IBEET-AA scheme, our construction can trace the well-formed pirated trapdoors. Given a well-formed pirated trapdoor $td_{ID,\, ID_t}'=\left((td_{ID,\, ID_t}')^1,\, (td_{ID,\, ID_t}')^2\right)$ relates to the user with $ID$ and tester $ID_t$. We have

which means the tester can be successfully traced. Note that although the PKG can generate new pirated trapdoor $td_{ID,\, ID_t}'$ for $(ID,\, ID_t)$, the dishonest PKG security of IBEET-AA prevents the PKG from extracting $(td_{ID,\, ID_t}')^1$ satisfying $(td_{ID,\, ID_t}')^1=td_{ID,\, ID_t}^1$, where the tester with $ID$ owns $td_{ID,\, ID_t}=\left(td_{ID,\, ID_t}^1,\right. \left. td_{ID,\, ID_t}^2\right)$. Moreover, the dishonest tester security prevents the tester from generating a different trapdoor $td_{ID,\, ID_t}'$ satisfying $(td_{ID,\, ID_t}')^1\neq (td_{ID,\, ID_t})^1$. Therefore, if $td_{ID,\, ID_t}'$ is generated by the tester with $ID_t$, we have $(td_{ID,\, ID_t}')^1=td_{ID,\, ID_t}^1$. Otherwise, if it is generated by the PKG, we have $(td_{ID,\, ID_t}')^1\neq td_{ID,\, ID_t}^1$. The tracing algorithm will then output correct tracing results.

6.   Security Analysis

Theorem 1. The proposed IBEET-AA scheme is secure.

Proof. According to Definition 1, we need to prove that the proposed IBEET-AA scheme is secure in OW-ID-CPA, IND-ID-CPA, dishonest authorizer, dishonest PKG, and dishonest tester games. We give the corresponding security proofs in Lemmas 1, 2, 3, 4, and 5, respectively.

Lemma 1. The proposed IBEET-AA scheme is OW-ID-CPA secure under the $q$-DABDHE assumption with a random oracle.

Proof. Let $H$ be a random oracle. Suppose there is an adversary $\mathcal{A}$ who can break the OW-ID-CPA security of the presented scheme with non-negligible advantage $\epsilon$, where it is allowed to make $q_h$ hash queries, $q_k$ private-key queries, and $q_t$ trapdoor queries. We can construct a simulator $\mathcal{B}$ to break the $q$-DABDHE assumption. Given a problem instance $g,\, g^a,\, g^{a^2},\, \ldots,\, g^{a^q},\, h,\, h^{a^{q+2}},\, Z$, $\mathcal{B}$ is to determine whether $Z=e(g,\, h)^{a^{q+1}}$ holds or not. $\mathcal{B}$ controls the random oracle $H$ and performs as follows.

1) Setup. $\mathcal{B}$ randomly chooses a $q$-degree polynomial $F(x)\in \mathbb{Z}_p[x]$ and implicitly sets $\alpha=a,\, \beta = F(a)$, and computes

which are all computable using $g^a,\, g^{a^2},\, \ldots,\, g^{a^q}$ in the given tuple. $\mathcal{B}$ sets $H$ to be a random oracle and chooses a cryptographic hash function $H_1: \{0,\, 1\}^*\rightarrow \mathbb{G}_T$. It publishes the system public parameter $pp$ as

2) Phase 1. In this phase, $\mathcal{A}$ is allowed to make $q_h$ hash queries, $q_k$ private key queries, and $q_t$ trapdoor queries on adaptively chosen identities.

a) Hash Query. $\mathcal{B}$ maintains a hash list $\mathcal{L}$ which is empty at the beginning to record the hash queries and responses. For a queried identity $ID_i$, $\mathcal{B}$ randomly picks $w_i\in \mathbb{Z}_p$ and sets

It then returns $H(ID_i)$ to $\mathcal{A}$ and stores the tuple $(ID_i,\, H(ID_i))$ to $\mathcal{L}$.

b) Private-Key Query. For a queried identity $ID_i$, $\mathcal{B}$ sets

and computes

which are all computable with the given $g^a,\, g^{a^2},\, \ldots,\, g^{a^{q-1}}$ in the given tuple. It then returns the private key $d_{ID_i}=(d_1,\, d_2)$ to $\mathcal{A}$.

c) Trapdoor Query. For a queried identity pair $(ID,\, ID_t)$, $\mathcal{B}$ first searches the hash list $\mathcal{L}$ to find the corresponding tuple $(ID_t,\, H(ID_t)=g^{w_t})$. If there is no such a tuple, $\mathcal{B}$ randomly picks $w_t\in \mathbb{Z}_p$, sets $H(ID_t)=g^{w_t}$, and stores the tuple $(ID_t,\, H(ID_t)= g^{w_t})$ to $\mathcal{L}$. $\mathcal{B}$ then generates the “partial” trapdoor following the below steps.

● $\mathcal{B}$ receives $R$ from $\mathcal{A}$. To be proven that $R=g^{\hat{r}}$, it interacts with $\mathcal{A}$ according to the ZKP illustrated in Fig.9. In the interaction, $\mathcal{B}$ aborts if the ZKP fails. Otherwise, it rewinds $\mathcal{A}$ to obtain $\hat{r}$^[26].

● $\mathcal{B}$ computes “partial” trapdoor $\overline{td}$ as

where $\overline{td_1} = w_t F(ID) + \hat{r}$ and

They are computable with known $w_t$. $\mathcal{B}$ sends $\overline{td}$ to $\mathcal{A}$.

● According to the key generation protocol, $\mathcal{A}$ will obtain its trapdoor as

which is a well-formed trapdoor. Moreover, $\mathcal{B}$ can also obtain this trapdoor with the known $w_t,\, g,\, g^a,\, \ldots, g^{a^{q-1}}$.

3) Challenge. Once $\mathcal{A}$ decides to finish Phase 1, it submits an identity $ID^*$ to $\mathcal{B}$ to be challenged. $\mathcal{B}$ randomly picks $M^*\in \mathcal{M}$ and generates the challenge ciphertext using $ID^*$ as below.

a) $\mathcal{B}$ computes a private key $d_{ID^*}$ for $ID^*$ as

where $f(x)=\dfrac{F(x)-F(ID^*)}{x-ID^*}$.

b) $\mathcal{B}$ implicitly sets $s= \log_g^h \, C(a)$, where

For simplicity, we set $l_i$ to be the coefficient of $x^i$ as above.

c) $\mathcal{B}$ computes

where $H(ID_t^*)=g^{w_t^*}$. $\mathcal{B}$ then returns the challenge ciphertext $CT^*$ to $\mathcal{A}$, where

4) Phase 2. In this phase, $\mathcal{A}$ can adaptively issue more private key queries and trapdoor queries with the restriction that $ID^*$ is not allowed to query in the private-key query phase. $\mathcal{B}$ responds to $\mathcal{A}$ in the same way as in Phase 1.

5) Attack. Finally, $\mathcal{A}$ outputs a message $M'$. If $M'=M^*$, $\mathcal{B}$ outputs 1 denoting that $Z=e(g,\, h)^{a^{q+1}}$. Otherwise, $\mathcal{B}$ outputs 0 denoting that $Z\neq e(g,\, h)^{a^{q+1}}$.

If $Z=e(g,\, h)^{a^{q+1}}$, the simulation is indistinguishable from the real system from the point of view of the adversary. Since $\mathcal{A}$ can win the OW-ID-CPA game with non-negligible advantage $\epsilon$, the probability of $\mathcal{A}$ in enabling $M'=M$ is $\epsilon$. $\mathcal{B}$, therefore, outputs 1 with non-negligible probability $\epsilon$. If $Z\neq e(g,\, h)^{a^{q+1}}$, it is a random number instead. The challenge ciphertext is a one-time pad. In this case, $\mathcal{A}$ can correctly output the message with negligible probability $1/| \mathbb{G}_T|$, where $| \mathbb{G}_T|$ denotes the size of group $\mathbb{G}_T$. $\mathcal{B}$ then outputs 1 with negligible probability $1/| \mathbb{G}_T|$. Therefore, the advantage of $\mathcal{B}$ in breaking the $q$-DABDHE assumption is

which is non-negligible. We have that the simulator can break the $q$-DABDHE assumption with non-negligible advantage. □

Lemma 2. The proposed IBEET-AA scheme is IND-ID-CPA secure under the $q$-DABDHE assumption with a random oracle.

Proof. The IND security proof of the proposed IBEET-AA scheme is almost the same as the OW security proof above, besides the challenge phase, Attack phase, and that $(ID^*,\, *)$ is not allowed to be queried to the trapdoor oracle.

1) Challenge. Once $\mathcal{A}$ decides to finish phase 1, it sends a challenge identity $ID^*$ and two messages $M_0^*,\, M_1^*\in \mathcal{M}$ to $\mathcal{B}$. $\mathcal{B}$ then randomly picks $b\in \{0,1\}$ and generates the challenge ciphertext $CT^*$ encrypted with $M_b^*$ and $ID^*$ as that in the OW-ID-CPA security proof.

2) Attack. $\mathcal{A}$ returns a guess $b'$ of $b$. If $b'=b$, $\mathcal{B}$ outputs 1 denoting that $Z=e(g,\, h)^{a^{q+1}}$. Otherwise, $\mathcal{B}$ outputs 0 denoting that $Z\neq e(g,\, h)^{a^{q+1}}$.

If $Z=e(g,\, h)^{a^{q+1}}$, the simulator is indistinguishable from the real system from the point of view of the adversary. Since the adversary can win the IND-ID-CPA game with non-negligible advantage $\epsilon$, the probability of $\mathcal{A}$ in correctly enabling $b'=b$ is $\epsilon+1/2$. $\mathcal{B}$ will then output 1 with probability $\epsilon+1/2$. If $Z\neq e(g,\, h)^{a^{q+1}}$, it is a random number instead. The challenge ciphertext is a one-time pad. In this case, $\mathcal{A}$ can correctly guess $b'$ such that $b'=b$ with probability $1/2$. $\mathcal{B}$ will output 1 with probability $1/2$. Therefore, the advantage of $\mathcal{B}$ in breaking the $q$-DABDHE assumption is:

which is non-negligible.□

Lemma 3. The proposed IBEET-AA scheme is dishonest authorizer secure under the $q$-SDH assumption with a random oracle.

Proof. Suppose there are $n$ identities of users. Let $H$ be a random oracle. Suppose there is an adversary $\mathcal{A}$ who acts as an authorizer can construct a pirated trapdoor $td_{ID,\, ID_t}$ for the tester owning $ID_t$ with non-negligible advantage $\epsilon$, where it is allowed to make $q_h$ hash queries, $q_k$ private-key queries, and $q_t$ trapdoor queries. We can construct a simulator $\mathcal{B}$ to break the $q$-SDH assumption. That means $\mathcal{B}$ can compute a tuple $(s, g^{\tfrac{1}{a+s}})$ for some $s\in \mathbb{Z}_p$ with non-negligible advantage, given a tuple $\left( g,\, g^a, \, \ldots,\, g^{a^q}\right)\in \mathbb{G}^{q+1}$ over $\mathbb{PG}$. $\mathcal{B}$ controls the oracle $H$ and performs as follows.

1) Setup. The same as the ``setup" step in the OW-ID-CPA security proof of Lemma 1.

2) Phase 1. The same as the ``phase 1" step in the OW-ID-CPA security proof of Lemma 1.

3) Challenge. $\mathcal{A}$ submits an identity pair $(ID^*,\, ID_t^*)$ to $\mathcal{B}$, where $(ID^*,\, ID_t^*)$ should not be queried to the trapdoor oracle in phase 1.

4) Attack. Finally, $\mathcal{A}$ outputs a trapdoor $td_{ID^*,\, ID_t^*}= \left( (td_{ID^*,\, ID_t^*})^1,\, (td_{ID^*,\, ID_t^*})^2\right)$.

5) Solve. Let $H(ID_t^*)=g^{w_t^*}$. With the private key $d_{ID^*}=(d_1^*,\, d_2^*)=\left( r^*,\, g^{\tfrac{\beta-r}{\alpha-ID^*}} \right)$ of $ID^*$, $\mathcal{B}$ computes

$\mathcal{B}$ then sets $(-ID^*,\, g^{\tfrac{1}{\alpha-ID^*}})$ as the solution to the given $q$-SDH problem instance.

Next, we analyze the advantage of $\mathcal{B}$ in successfully solving the given $q$-SDH problem instance. Since $\mathcal{A}$ can construct a well-formed pirated trapdoor with non-negligible probability $\epsilon$, we have

Let $W=\dfrac{1}{w_t^* \, d_1^*-(td_{ID^*,\, ID_t^*})^1}$, we then have

Therefore, $(-ID^*,\, g^{\tfrac{1}{\alpha-ID^*}})$ is a solution to the given $q$-SDH problem instance with non-negligible probability $\epsilon$. This implies a fact that if $\mathcal{A}$ can successfully return a well-formed trapdoor with non-negligible advantage $\epsilon$, $\mathcal{B}$ can solve the given $q$-SDH problem instance with non-negligible advantage $\epsilon$.□

Lemma 4. The proposed IBEET-AA scheme is dishonest PKG secure under the DL assumption.

Proof. Suppose there is an adversary $\mathcal{A}$ who can break our scheme in the dishonest PKG game with non-negligible advantage $\epsilon$. We can construct a simulator $\mathcal{B}$ to break the DL assumption. $\mathcal{B}$ performs as follows.

1) Setup. $\mathcal{B}$ receives $mpk$ and a challenge identity pair $(ID^*,\, ID_t^*)$ from $\mathcal{A}$.

2) KeyGen. $\mathcal{B}$ receives $d_{ID^*}=(d_1^*,\, d_2^*)$ from $\mathcal{A}$.

3) Aut. To obtain a corresponding trapdoor of $(ID^*,\, ID_t^*)$, $\mathcal{B}$ performs the following steps.

a) $\mathcal{B}$ implicitly sets $\hat{r}=a$ and computes $R=g^{\hat{r}} = g^a$ which is computable with the given tuple.

b) To prove to $\mathcal{A}$ that $R=g^{\hat{r}} = g^a$ in the ZKP as Fig.9, $\mathcal{B}$ first rewinds $\mathcal{A}$ to obtain $c$ and interacts with $\mathcal{A}$ as illustrated in Fig.10. In the proof, $\mathcal{B}$ randomly picks $s\in \mathbb{Z}_p$ and computes $y=g^s \, R^c$. It is easy to see the ZKP will succeed.

Figure  10.  ZKP of $R$ in dishonest PKG game.

下载: 全尺寸图片 幻灯片

c) $\mathcal{B}$ receives the “partial” trapdoor $\overline{td}$ from $\mathcal{A}$, where

$\mathcal{B}$ checks whether the following equation holds and aborts if it fails.

4) Frame. Finally, $\mathcal{A}$ outputs a pirated trapdoor $td_{ID^*,\, ID_t^*}'$. Let

5) Solve. $\mathcal{B}$ computes

Let $td_{ID^*,\, ID_t^*}=\left( td_{ID^*,\, ID_t^*}^1,\, td_{ID^*,\, ID_t^*}^2\right)$ be the trapdoor which should be obtained by $\mathcal{B}$ with the received “partial” trapdoor and the knowledge of $a$. We have that $td_{ID^*,\, ID_t^*}^1 = \overline{td_1} - \hat{r}=\overline{td_1} - a$. Since $\mathcal{A}$ can win the dishonest PKG game with an advantage $\epsilon$, the tracing algorithm will determine the generator of the pirated trapdoor $td_{ID^*,\, ID_t^*}'$ to be the tester with non-negligible probability, which means the following equation will hold with non-negligible advantage $\epsilon$.

That implies $\mathcal{B}$ can obtain a correct computation of $a$ with an advantage $\epsilon$. Therefore, $\mathcal{B}$ can break the DL assumption with non-negligible advantage $\epsilon$. □

Lemma 5. The proposed IBEET-AA scheme is dishonest tester secure under the $q$-SDH assumption.

Proof. We claim that this security proof is similar to that of Lemma 6, and therefore we omit the specific proof here. If $\mathcal{A}$ who acts as a malicious tester can break the dishonest tester security of the proposed IBEET-AA scheme, it can output two trapdoors as

$\mathcal{B}$ can extract

and set $(-ID^*,\, g^{\tfrac{1}{a-ID^*}} )$ as the solution to the given $q$-SDH problem instance. Hence if $\mathcal{A}$ can break the dishonest tester security with non-negligible advantage $\epsilon$, $\mathcal{B}$ can break the $q$-SDH assumption with non-negligible advantage $\epsilon$. □

This completes the security proof of the proposed IBEET-AA scheme. Following Definition 1, we have that our IBEET-AA scheme is secure.

7.   Conclusions

To relieve the key escrow problem in IBEET when being applied in cloud computing, we proposed a new notion, called IBEET-AA to support generator tracing of pirated trapdoors among the private-key generator (PKG) and suspected testers. In IBEET-AA, the PKG interacts with the authorized cloud server to generate the trapdoor, while the PKG generates trapdoors for authorized cloud servers alone in traditional IBEET. The interaction in trapdoor generation protects that only the cloud server itself knows the exact trapdoor and the PKG has no idea about which trapdoor the server finally obtains, although the trapdoor is generated with the help of the PKG. This enables the accountability of disputed trapdoors in IBEET-AA. For this presented notion, we also designed three new security models against dishonest authorizers, the PKG, and testers to protect the tracing security, except for the traditional IND and OW security model for message confidentiality as that in traditional IBEET. These three new security models guarantee that the authorizer cannot generate a valid trapdoor, and the PKG and a tester cannot frame each other by generating a trapdoor whose generator will be determined as the other party. We constructed a specific scheme and proved its security under five designed security models.