1
Identity-based Encryption with Outsourced Revocation in
Cloud Computing
Jin Li, Jingwei Li, Xiaofeng Chen, Chunfu Jia and Wenjing Lou, Senior Member, IEEE
Abstract—Identity-Based Encryption (IBE) which simplifies the
public key and certificate management at Public Key Infrastructure
(PKI) is an important alternative to public key encryption. However,
one of the main efficiency drawbacks of IBE is the overhead computa-
tion at Private Key Generator (PKG) during user revocation. Efficient
revocation has been well studied in traditional PKI setting, but the
cumbersome management of certificates is precisely the burden that
IBE strives to alleviate.
In this paper, aiming at tackling the critical issue of identity
revocation, we introduce outsourcing computation into IBE for the
first time and propose a revocable IBE scheme in the server-aided
setting. Our scheme offloads most of the key generation related
operations during key-issuing and key-update processes to a Key
Update Cloud Service Provider, leaving only a constant number
of simple operations for PKG and users to perform locally. This
goal is achieved by utilizing a novel collusion-resistant technique: we
employ a hybrid private key for each user, in which an AND gate is
involved to connect and bound the identity component and the time
component. Furthermore, we propose another construction which is
provable secure under the recently formulized Refereed Delegation
of Computation model. Finally, we provide extensive experimental
results to demonstrate the efficiency of our proposed construction.
Index Terms—Identity-based encryption, Revocation, Outsourcing,
Cloud computing.
I. INTRODUCTION
Identity-Based Encryption (IBE) is an interesting alternative
to public key encryption, which is proposed to simplify key
management in a certificate-based Public Key Infrastructure (PKI)
by using human-intelligible identities (e.g., unique name, email
address, IP address, etc) as public keys. Therefore, sender using
IBE does not need to look up public key and certificate, but
directly encrypts message with receiver’s identity. Accordingly,
receiver obtaining the private key associated with the correspond-
ing identity from Private Key Generator (PKG) is able to decrypt
such ciphertext.
Though IBE allows an arbitrary string as the public key which
is considered as an appealing advantages over PKI, it demands an
efficient revocation mechanism. Specifically, if the private keys of
some users get compromised, we must provide a mean to revoke
such users from system. In PKI setting, revocation mechanism
is realized by appending validity periods to certificates or using
involved combinations of techniques [1][2][3]. Nevertheless, the
cumbersome management of certificates is precisely the burden
that IBE strives to alleviate.
As far as we know, though revocation has been thoroughly
studied in PKI, few revocation mechanisms are known in IBE
Jin Li is with the School of Computer Science, Guangzhou University,
China, e-mail: lijin@gzhu.edu.cn.
Jingwei Li and Chunfu Jia are with the College of Information Techni-
cal Science, Nankai University, China, e-mail: lijw@mail.nankai.edu.cn,
cfjia@nankai.edu.cn.
Xiaofeng Chen is with the State Key Laboratory of Integrat-
ed Service Networks (ISN), Xidian University, Xi’an, China, e-mail:
xfchen@xidian.edu.cn.
Wenjing Lou is with Virginia Polytechnic Institute and State University,
USA, e-mail: wjlou@vt.edu.
setting. In [4], Boneh and Franklin suggested that users renew their
private keys periodically and senders use the receivers’ identities
concatenated with current time period. But this mechanism would
result in an overhead load at PKG. In another word, all the users
regardless of whether their keys have been revoked or not, have
to contact with PKG periodically to prove their identities and
update new private keys. It requires that PKG is online and the
secure channel must be maintained for all transactions, which will
become a bottleneck for IBE system as the number of users grows.
In 2008, Boldyreva, Goyal and Kumar [5] presented a revocable
IBE scheme. Their scheme is built on the idea of fuzzy IBE
primitive [6] but utilizing a binary tree data structure to record
users’ identities at leaf nodes. Therefore, key-update efficiency
at PKG is able to be significantly reduced from linear to the
height of such binary tree (i.e. logarithmic in the number of users).
Nevertheless, we point out that though the binary tree introduction
is able to achieve a relative high performance, it will result in other
problems: 1) PKG has to generate a key pair for all the nodes on
the path from the identity leaf node to the root node, which results
in complexity logarithmic in the number of users in system for
issuing a single private key. 2) The size of private key grows
in logarithmic in the number of users in system, which makes
it difficult in private key storage for users. 3) As the number of
users in system grows, PKG has to maintain a binary tree with
a large amount of nodes, which introduces another bottleneck for
the global system.
In tandem with the development of cloud computing, there
has emerged the ability for users to buy on-demand computing
from cloud-based services such as Amazon’s EC2 and Microsoft’s
Windows Azure. Thus it desires a new working paradigm for
introducing such cloud services into IBE revocation to fix the
issue of efficiency and storage overhead described above. A naive
approach would be to simply hand over the PKG’s master key to
the Cloud Service Providers (CSPs). The CSPs could then simply
update all the private keys by using the traditional key update
technique [4] and transmit the private keys back to unrevoked
users. However, the naive approach is based on an unrealistic
assumption that the CSPs are fully trusted and is allowed to access
the master key for IBE system. On the contrary, in practice the
public clouds are likely outside of the same trusted domain of
users and are curious for users’ individual privacy. For this reason,
a challenge on how to design a secure revocable IBE scheme to
reduce the overhead computation at PKG with an untrusted CSP
is raised.
In this paper, we introduce outsourcing computation into IBE
revocation, and formalize the security definition of outsourced
revocable IBE for the first time to the best of our knowledge.
We propose a scheme to offload all the key generation related
operations during key-issuing and key-update, leaving only a
constant number of simple operations for PKG and eligible users
to perform locally. In our scheme, as with the suggestion in
[4], we realize revocation through updating the private keys of
the unrevoked users. But unlike that work [4] which trivially
concatenates time period with identity for key generation/update
Digital Object Indentifier 10.1109/TC.2013.208 0018-9340/13/$31.00 © 2013 IEEE
IEEE TRANSACTIONS ON COMPUTERS
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
2
and requires to re-issue the whole private key for unrevoked users,
we propose a novel collusion-resistant key issuing technique: we
employ a hybrid private key for each user, in which an AND gate
is involved to connect and bound two sub-components, namely the
identity component and the time component. At first, user is able
to obtain the identity component and a default time component
(i.e., for current time period) from PKG as his/her private key
in key-issuing. Afterwards, in order to maintain decryptability,
unrevoked users needs to periodically request on key-update for
time component to a newly introduced entity named Key Update
Cloud Service Provider (KU-CSP).
Compared with the previous work [4], our scheme does not
have to re-issue the whole private keys, but just need to update
a lightweight component of it at a specialized entity KU-CSP.
We also specify that 1) with the aid of KU-CSP, user needs
not to contact with PKG in key-update, in other words, PKG is
allowed to be offline after sending the revocation list to KU-CSP.
2) No secure channel or user authentication is required during
key-update between user and KU-CSP.
Furthermore, we consider to realize revocable IBE with a semi-
honest KU-CSP. To achieve this goal, we present a security
enhanced construction under the recently formalized Refereed
Delegation of Computation (RDoC) model [7]. Finally, we provide
extensive experimental results to demonstrate the efficiency of our
proposed construction.
This paper is organized as follows. In Section II, we describe
the preliminaries of our scheme. In Section III, we present the
system model and security definition of our scheme. The proposed
construction, and its security analysis are presented in Section
IV. In Section V, we propose a security enhanced construction
under RDoC model. An extensive experimental result is presented
in Section VI to demonstrate the efficiency of our proposed
constructions. Finally, After revisiting the related work in Section
VII, we draw conclusion in Section VIII.
II. P
RELIMINARY
In this section, we give a brief review on some cryptographic
background and identity based encryption.
A. Cryptographic Background
Definition 1: (Bilinear map) Let G, G
T
be cyclic groups of
prime order q, writing the group action multiplicatively. g is a
generator of G . Let e : G ×G → G
T
be a map with the following
properties:
• Bilinearity: e(g
a
1
,g
b
2
)=e(g
1
,g
2
)
ab
for all g
1
,g
2
∈ G, and
a, b ∈
R
Z
q
;
• Non-degeneracy: There exists g
1
,g
2
∈ G with e(g
1
,g
2
) =1,
in other words, the map does not send all pairs in G × G to
the identity in G
T
;
• Computability: There is an efficient algorithm to compute
e(g
1
,g
2
) for all g
1
,g
2
∈ G.
Definition 2: (DBDH problem) The decision Bilinear Diffie-
Hellman (DBDH) problem is that, given g, g
x
, g
y
, g
z
∈ G for
unknown random value x, y, z ∈
R
Z
q
, and T ∈
R
G
T
, to decide
if T = e(g, g)
xyz
.
We say that the (t, )-DBDH assumption holds in G if no t-
time algorithm has probability at least
1
2
+ in solving the DBDH
problem for non-negligible .
Fig. 1. System Model for IBE with Outsourced Revocation
B. Identity-based Encryption
An IBE scheme which typically involves two entities, PKG and
users (including sender and receiver) is consisted of the following
four algorithms.
• Setup(λ):The setup algorithm takes as input a security
parameter λ and outputs the public key PK and the master
key MK. Note that the master key is kept secret at PKG.
• KeyGen(MK,ID) : The private key generation algorithm is
run by PKG, which takes as input the master key MK and
user’s identity ID ∈{0, 1}
∗
. It returns a private key SK
ID
corresponding to the identity ID.
• Encrypt(M,ID
):The encryption algorithm is run by
sender, which takes as input the receiver’s identity ID
and
a message M to be encrypted. It outputs the ciphertext CT.
• Decrypt(CT,SK
ID
):The decryption algorithm is run by
receiver, which takes as input the ciphertext CT and his/her
private key SK
ID
. It returns a message M or an error ⊥.
An IBE scheme must satisfy the definition of consisten-
cy. Specifically, when the private key SK
ID
generated by
algorithm KeyGen when it is given ID as the input, then
Decrypt(CT,SK
ID
)=M where CT = Encrypt(M,ID).
The motivation of IBE is to simplify certificate manage-
ment. For example, when Alice sends an email to Bob at
bob@company.com, she simply encrypts her message using
Bob’s email address “bob@company.com”, but does not need
to obtain Bob’s public key certificate. When Bob receives the
encrypted email he authenticate himself at PKG to obtain his
private key, and read his email with such a private key.
III. P
ROBLEM STATEMENT
A. System Model
We present system model for outsourced revocable IBE in Fig.
1. Compared with that for typical IBE scheme, a KU-CSP is
involved to realize revocation for compromised users. Actually,
the KU-CSP can be envisioned as a public cloud run by a
third party to deliver basic computing capabilities to PKG as
standardized services over the network. Typically, KU-CSP is
hosted away from either users or PKG, but provides a way to
reduce PKG computation and storage cost by providing a flexible,
even temporary extension to infrastructure. When revocation is
triggered, instead of re-requesting private keys from PKG in
[4], unrevoked users have to ask the KU-CSP for updating a
lightweight component of their private keys. Though many details
are involved in KU-CSP’s deployment, in this paper we just
logically envision it as a computing service provider, and concern
how to design secure scheme with an untrust KU-CSP.
Based on the system model proposed, we are able to define the
outsourced revocable IBE scheme. Compared with the traditional
IEEE TRANSACTIONS ON COMPUTERS
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
3
IBE definition, the KeyGen, Encrypt and Decrypt algorithms are
redefined as follows to integrate time component. Note that two
lists RL and TL are utilized in our definition, where RL records
the identities of revoked users and TL is a linked list for past and
current time period.
• KeyGen(MK,ID,RL,TL):The key generation algorithm
run by PKG takes as input – a master key MK, an identity
ID, a revocation list RL and a time list TL.IfID ∈ RL,
the algorithm is aborted. Otherwise, it sends the private key
SK
ID
=(IK[ID],TK[ID]
T
i
) to user where IK[ID] is the
identity component for private key SK
ID
and TK[ID]
T
i
is
its time component for current time period T
i
. Additionally,
the algorithm sends an outsourcing key OK
ID
to KU-CSP.
• Encrypt(M,ID,T
i
,PK):The encryption algorithm run by
sender takes as input – a message M, an identity ID and a
time period T
i
. It outputs the ciphertext CT.
• Decrypt(CT,SK
ID
):The decryption algorithm run by
receiver takes as input – a ciphertext CT encrypted under
identity ID and time period T
i
and a private key SK
ID
=
(IK[ID
],TK[ID
]
T
j
). It outputs the original message M
if ID = ID
and T
i
= T
j
, otherwise outputs ⊥.
In addition, two algorithms are defined to realize revocation at
KU-CSP through updating the private keys of unrevoked users.
• Revoke(RL, T L, {ID
i
1
,...,ID
i
k
}):The revocation algo-
rithm run by PKG takes as input – a revocation list RL,
a time list TL and the set of identities to be revoked
{ID
i
1
, ID
i
2
,...,ID
i
k
}. It outputs an updated time period
T
i+1
as well as the updated revocation list RL
and time list
TL
.
• KeyUpdate(RL, ID,T
i+1
,OK
ID
):The key update algo-
rithm run by KU-CSP takes as input – a revocation list
RL, an identity ID, a time period T
i+1
and the outsourcing
key OK
ID
for identity ID. It outputs user’s updated time
component in private key TK[ID]
T
i+1
if his identity ID does
not belong to RL, otherwise, outputs ⊥.
In this paper, we discuss user revocation, that is how to deprive
users of decryptability even if they have been issued their private
keys. To this end, we embed a time period into private key in a
clever manner for revocation. Specifically, in the same example
illustrated in Section II-B, Alice in our setting not only encrypts
message with Bob’s email address “ bob@company.com”but
also with current time period (e.g., “Thu Jul 18 2013”). When
receives the encrypted email, Bob then obtains his private key
consisting of an identity component and a time period component
from PKG. With the both appropriate components, the email can
be read.
Suppose Bob is compromised. Then, the time components of
all the other users are updated by KU-CSP with a new time
period (e.g., “Fri Jul 19 2013”). From then on, the message sent
to Bob should be encrypted with Bob’s email address and the
updated time period. Since Bob does not have the time component
corresponding to the updated time period, the following encrypted
messages can not be decrypted by Bob even if they are intended
for him.
The challenge in designing the outsourced revocable IBE
scheme is how to prevent a collusion between Bob and other
unrevoked dishonest users. Specifically, a dishonest user (named
Eve) can share her updated time component (i.e., “Fr i Jul 19
2013”) with Bob, and help Bob decrypt ciphertext even if Bob
just has the previous one (i.e., “Thu Jul 18 2013”). We will show
how to avoid such a collusion later.
B. Security Definition
We assume that KU-CSP in the proposed system model is semi-
trusted. Specifically, it will follow our protocol but try to find out
as much secret information as possible based on its possession.
Therefore, two types of adversaries are to be considered as
follows.
• Type-I adversary. It is defined as a curious user with identity
ID but revoked before time period T
i
. Such adversary tries
to obtain useful information from ciphertext intended for
him/her at or after T
i
(e.g. time period T
i
,T
i+1
,...) through
colluding with other users even if they are unrevoked. There-
fore, it is allowed to ask for private key including identity
component and updated time component for cooperative
users. We specify that under the assumption that KU-CSP
is semi-trusted, type-I adversary cannot get outsourcing key
for any users.
• Type-II adversary. It is defined as a curious KU-CSP which
aims to obtain useful information from ciphertext intended
for some target identity ID at time period T
i
. Such adversary
not only possess of outsourcing keys for all users in the
system, but also is able to get user’s private key through
colluding with any other user with identity ID
. It is noted
that to make such attack reasonable, we must restrict ID
=
ID.
Having the intuitions above, we are able to define CCA security
game for type-I and type-II adversary respectively for our setting
in Fig. 2. Suppose A
i
is the type-i adversary for i =I, II. Then, its
advantage in attacking the IBE with outsourced revocation scheme
E is defined as Adv
E,A
i
(λ)=|Pr[b
i
= b
i
] −
1
2
|.
Definition 3: An identity-based encryption with outsourced re-
vocation scheme is semantically secure against adaptive chosen-
ciphertext attack (IND-ID-CCA) if no polynomially bounded ad-
versary has a non-negligible advantage against challenger in
security game for both type-I and type-II adversary.
Finally, beyond the CCA security, we also specify that 1)
An IBE with outsourced revocation scheme is IND-ID-CPA
secure (or semantically secure against chosen-plaintext attack)
if no polynomial time adversary has non-negligible advantage
in modified games for both type-I and type-II adversary, in
which the decryption oracle in both phase 1 and phase 2 is
removed; 2) An IBE with outsourced revocation scheme is secure
in selective model if no polynomial time adversary has non-
negligible advantage in modified games for both type-I and type-
II adversary, in which the challenge identity and time period is
submitted before setup.
IV. E
FFICIENT IBE WITH OUTSOURCED REVOCATION
A. Intuition
In order to achieve efficient revocation, we introduce the idea of
“partial private key update” into the proposed construction, which
operates on two sides: 1) We utilize a “hybrid private key” for
each user in our system, which employs an AND gate connecting
two sub-components namely the identity component IK and the
time component TK respectively. IK is generated by PKG in
key-issuing but TK is updated by the newly introduced KU-CSP
in key-update; 2) In encryption, we take as input user’s identity ID
as well as the time period T to restrict decryption, more precisely,
a user is allowed to perform successful decryption if and only if
the identity and time period embedded in his/her private key are
identical to that associated with the ciphertext. Using such skill,
we are able to revoke user’s decryptability through updating the
time component for private key by KU-CSP.
IEEE TRANSACTIONS ON COMPUTERS
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
4
CCA Security Game for Type-I Adversary
Setup: Challenger runs Setup(λ) to obtain the key pair (PK,MK) and output PK.
Phase 1: Challenger initializes an empty table list L and an empty set S. Adversary is provided the following oracles.
• Private key extraction oracle. Upon receiving ID, run KeyGen to obtain SK
ID
=(IK[ID],TK[ID]
T
i
) and OK
ID
. After
adding the entry (ID,SK
ID
,OK
ID
) into L, output IK[ID].
• Updated key extraction oracle. Upon receiving ID and T
j
, if there exists an entry of (ID,SK
ID
,OK
ID
) in L, set
S = S ∪{(ID,T
j
)}. Accordingly, run KeyUpdate and output the updated key TK[ID]
T
j
.
• Decryption oracle. Upon receiving ID, T
j
and CT, run Decrypt and output the resulting plaintext M.
Challenge: Adversary outputs two equal-length plaintexts M
0
,M
1
, T
∗
and ID
∗
with the restriction that (ID
∗
,T
∗
) /∈ S.
Challenger picks a random bit b
I
∈{0, 1} and sets CT
∗
= Encrypt(M
b
I
, ID
∗
,T
∗
,PK).
Phase 2: Adversary adaptively issues more queries as in phase 1 with the restriction that (ID
∗
,T
∗
) cannot be queried in updated
key extraction oracle.
Guess: Finally, adversary outputs a guess b
I
∈{0, 1} and wins the game if b
I
= b
I
.
CCA Security Game for Type-II Adversary
Setup: It is identical to the setup phase in the CCA security game for type-I adversary.
Phase 1: Challenger initializes an empty table list L, and two empty sets U and I. Then, adversary is provided the following
oracles.
• Outsourcing key extraction oracle. Upon receiving ID, challenger runs KeyGen to obtain SK
ID
=(IK[ID],TK[ID]
T
i
)
and OK
ID
. After adding the entry (ID,SK
ID
,OK
ID
) into L, output OK
ID
.
• Private key extraction oracle. Upon receiving ID, if there exists an entry (ID,SK
ID
,OK
ID
) in L, set U = U ∪{ID}
and return IK[ID] back to adversary.
• Updated key extraction oracle. Upon receiving ID and T
j
, if there exists an entry (ID,SK
ID
,OK
ID
) in L, check on
whether ID ∈ U , if not set I = I ∪{T
j
}. Then, run KeyUpdate and output TK[ID]
T
j
.
• Decryption oracle. It is identical to the decryption oracle in the CCA security game for type-I adversary.
Challenge: Adversary outputs two equal-length plaintexts M
0
,M
1
, T
∗
and ID
∗
with the restriction that T
∗
/∈ I and ID
∗
/∈ U.
Challenger picks a random bit b
II
∈{0, 1} and sets CT
∗
= Encrypt(M
b
II
, ID
∗
,T
∗
,PK).
Phase 2: Adversary adaptively issues more queries as in phase 1 with the restrictions that i) ID
∗
cannot be queried in private
key extraction oracle; ii) (ID
∗
,T
∗
) cannot be queried in updated key extraction oracle.
Guess: Finally, adversary outputs a guess b
II
∈{0, 1} and wins the game if b
II
= b
II
.
Fig. 2. CCA Security Game for Type-I and Type-II Adversary
Moreover, we remark that it cannot trivially utilize an identical
updated time component for all users because revoked user is able
to re-construct his/her ability through colluding with unrevoked
users. To eliminate such collusion, we randomly generate an
outsourcing key for each identity ID, which essentially decides a
“matching relationship” for the two sub-components. Furthermore,
we let KU-CSP maintain a list UL to record user’s identity and its
corresponding outsourcing key. In key-update, we can use OK
ID
to update the time component TK[ID]
T
for identity ID. Suppose
a user with identity ID is revoked at T
i
. Even if he/she is able to
obtain TK[ID
]
T
i+1
for identity ID
, the revoked user still cannot
decrypt ciphertext encrypted under T
i+1
.
B. Proposed Construction
We present our construction based on [6] as follows.
• Setup(λ):The setup algorithm is run by PKG. It selects a
random generator g ∈
R
G as well as a random integer x ∈
R
Z
q
, and sets g
1
= g
x
. Then, PKG picks a random element
g
2
∈
R
G and two hash functions H
1
,H
2
: {0, 1}
∗
→ G
T
.
Finally, output the public key PK =(g,g
1
,g
2
,H
1
,H
2
) and
the master key MK = x.
• KeyGen(MK,ID,RL,TL,PK):For each user’s private
key request on identity ID, PKG firstly checks whether the
request identity ID exists in RL, if so the key generation
algorithm is aborted. Next, PKG randomly selects x
1
∈
R
Z
q
and sets x
2
= x − x
1
mod q. It randomly chooses r
ID
∈
R
Z
q
, and computes IK[ID] = (g
x
1
2
· (H
1
(ID))
r
ID
,g
r
ID
).
Then, PKG reads the current time period T
i
from TL
(we require that PKG should create current time period
firstly if TL is empty). Accordingly, it randomly selects
r
T
i
∈
R
Z
q
and computes TK[ID]
T
i
=(d
T
i
0
,d
T
i
1
), where
d
T
i
0
= g
x
2
2
· (H
2
(T
i
))
r
T
i
and d
T
i
1
= g
r
T
i
. Finally, output
SK
ID
=(IK[ID],TK[ID]
T
i
) and OK
ID
= x
2
.
• Encrypt(M,ID,T
i
,PK):Suppose a user wishes to en-
crypt a message M under identity ID and time period T
i
.
He/She selects a random value s ∈
R
Z
q
and computes
C
0
= Me(g
1
,g
2
)
s
, C
1
= g
s
, E
ID
=(H
1
(ID))
s
and
E
T
i
=(H
2
(T
i
))
s
. Finally, publish the ciphertext as CT =
(C
0
,C
1
,E
ID
,E
T
i
).
• Decrypt(CT,SK
ID
,PK):Suppose that the ciphertext CT
is encrypted under ID and T
i
, and the user has a private key
SK
ID
=(IK[ID],TK[ID]
T
i
), where IK[ID] = (d
0
,d
1
)
and TK[ID]
T
i
=(d
T
i
0
,d
T
i
1
). He/She computes
M =
C
0
e(d
1
,E
ID
)e(d
T
i
1
,E
T
i
)
e(C
1
,d
0
)e(C
1
,d
T
i
0
)
=
Me(g
1
,g
2
)
s
e(g, g
2
)
x
2
s
e(g, g
2
)
x
1
s
= M
IEEE TRANSACTIONS ON COMPUTERS
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
5
Fig. 3. A Comparison on Generating Private Key for Two Different Users
• Revoke(RL, T L, {ID
i
1
, ID
i
2
,...,ID
i
k
}):If users with
identities in the set {ID
i
1
, ID
i
2
,...,ID
i
k
} are to be revoked
at time period T
i
, PKG updates the revocation list as RL
=
RL∪{ID
i
1
, ID
i
2
,...,ID
i
k
} as well as the time list through
linking the newly created time period T
i+1
onto original list
TL. Finally send a copy for the updated revocation list RL
as well as the new time period T
i+1
to KU-CSP.
• KeyUpdate(RL, ID,T
i+1
,OK
ID
):Upon receiving a key-
update request on ID, KU-CSP firstly checks whether ID
exists in the revocation list RL, if so KU-CSP returns ⊥
and key-update is aborted. Otherwise, KU-CSP fetches the
corresponding entry (ID,OK
ID
= x
2
) in the user list UL.
Then, it randomly selects r
T
i+1
∈
R
Z
q
, and computes
d
T
i+1
0
= g
x
2
2
· (H
2
(T
i+1
))
r
T
i+1
and d
T
i+1
1
= g
r
T
i+1
.
Finally, output TK[ID]
T
i+1
=(d
T
i+1
0
,d
T
i+1
1
).
1
Finally, we emphasize that the idea behind our construction
is to realize revocation through updating the time component in
private key. Therefore, the key point is to prevent revoked user
from colluding with other users to re-construct his/her private key.
As declaring in intuition, such collusion attack is resistant in our
proposed construction due to the random split on x for each user.
Specifically, as shown in Fig. 3 in which ∧ is an AND gate
connecting two sub-components, if two different users call for
their private keys, PKG will obtain two randomly splits (x
1
,x
2
)
and (x
1
,x
2
) with the complementary that x
1
+x
2
= x mod q and
x
1
+ x
2
= x mod q. x
1
and x
1
are used to produce the identity
component for ID and ID
respectively, while the time component
is separately generated from x
2
and x
2
. By the reason that the
complementary exists between x
1
and x
2
as well as x
1
and x
2
,
the identity component and time component should accordingly
have a “verification” in private key. With such “verification”, even
if a curious user obtains time component of other users, he/she
cannot forge a valid private key for himself to perform decryption
successfully.
C. Key Service Procedures
Based on our algorithm construction, as shown in Fig. 4,
the key service procedures including key-issuing, key-update and
revocation in proposed IBE scheme with outsourced revocation
work as follows.
• Key-issuing. We require that PKG maintains a revocation list
RL and a time list TL locally. Upon receiving a private key
request on ID, PKG runs KeyGen(MK,ID,RL,TL,PK)
to obtain private key SK
ID
and outsourcing key OK
ID
.
Finally, it sends SK
ID
to user and (ID,OK
ID
) to KU-
CSP respectively. As described in intuition, for each entry
1
No secure communication channel is required between user and KU-
CSP. Furthermore, it is no need for the identity authentication which
relieves the computational overhead at user side.
(ID,OK
ID
) sent from PKG, KU-CSP should add it into a
locally maintained user list UL.
• Key-update. If some users have been revoked at time
period T
i
, each unrevoked user needs to send key-
update request to KU-CSP to maintain decryptability. Up-
on receiving the request on identity ID, KU-CSP runs
KeyUp date (RL, ID,T
i+1
,OK
ID
) to obtain TK[ID]
T
i+1
.
Finally, it sends such time component back to user
who is able to update his/her private key as SK
ID
=
(IK[ID],TK[ID]
T
i+1
).
• Revocation. Similar to key-update, if a revoked user send-
s a key-update request on identity ID, KU-CSP runs
KeyUp date (RL, ID,T
i+1
,OK
ID
) as well. Nevertheless, s-
ince ID ∈ RL, KU-CSP will return ⊥. Therefore, such key-
update request is aborted.
D. Security Analysis
Theorem 1: Suppose that the (t, )−DBDH assumption holds
in G and hash functions H
1
and H
2
are random oracles. Suppose
the adversary makes at most q
H
1
, q
H
2
, q
P
,q
U
and q
O
queries to
hash functions H
1
,H
2
, private key, updated key and outsourcing
key extraction oracles respectively. We use t
EXP
to denote time
cost for single multi-based exponentiation operation in G. Then
the proposed IBE with outsourced revocation scheme is (t
,
)
secure in the sense of IND-ID-CPA where t
≈ t +(q
H
1
+ q
H
2
+
3q
P
+3q
U
)t
EXP
and
=
1
q
H
1
q
H
2
.
Proof: Assume that an adversary A
I
and A
II
have advantage
I
and
II
in attacking the proposed IBE scheme in the sense
of IND-ID-CPA security for type-I and type-II adversary respec-
tively. We will build two simulators S
I
and S
II
that respectively
uses A
I
and A
II
as a sub-algorithm to solve the decisional BDH
problem with a non-negligible probability.
Suppose challenger in DBDH problem flips a fair binary coin μ
outside of S
I
and S
II
’s view. If μ =0, then S
I
and S
II
are given
(X = g
x
,Y = g
y
,Z = g
z
,P = e(g, g)
xyz
); otherwise, (X =
g
x
,Y = g
y
,Z = g
z
,P = e(g, g)
v
) for random x, y, z, v
R
←− Z
q
.
S
I
and S
II
are asked to output a value μ
as the guess for μ. Then
we provide simulations as follows.
Simulation of S
I
against Type-I Adversary
Setup: S
I
sets g
1
= X, g
2
= Y and sends the public key PK =
(g, g
1
,g
2
) to A
I
.
Phase 1: S
I
initializes an empty table list L, and an empty set S.
A
I
is allowed to issue queries in the following types.
• H
1
-query. S
I
randomly picks κ ∈
R
{1, 2,...,q
H
1
} and
maintains a list L
1
to store the answers to the hash oracle H
1
.
Upon receiving ID
i
for 1 ≤ i ≤ q
H
1
, S
I
performs a check
on L
1
. If an entry for the query is found, the same answer
will be returned. Otherwise, S
I
randomly selects u
i
∈
R
Z
q
and computes
H
1
(ID
i
)=
g
u
i
1
i = κ
g
u
κ
i = κ
After storing the entry (ID
i
,u
i
) in L
1
, S
I
returns H
1
(ID
i
).
• H
2
-query. S
I
randomly picks η ∈
R
{1, 2,...,q
H
2
} and
maintains a list L
2
to store the answers to the hash oracle H
2
.
Upon receiving T
j
for 1 ≤ j ≤ q
H
2
, S
I
performs a check
on L
2
. If an entry for the query is found, the same answer
will be returned. Otherwise, S
I
randomly selects v
j
∈
R
Z
q
and computes
H
2
(T
j
)=
g
v
j
1
j = η
g
v
η
i = η
IEEE TRANSACTIONS ON COMPUTERS
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
