188 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 13, NO. 1, JANUARY 2018
like to review the ABE schemes with revocability. In 2008,
Boldyreva et al. [27] introduced a revocable ABE scheme
which extended from their main contribution, a revocable IBE.
In their scheme, the non-revoked users need to update their
private keys periodically which is quite inconvenient. To solve
this problem, Attrapadung et al. [28] proposed a new ABE
scheme with revocability, where the non-revoked users do not
need to update their private keys periodically any more, but
the sender needs to know the revocation list. To address this
problem, at the same year, Attrapadung et al. [29] proposed
another ABE scheme, where the authors conclude that there
are two methods to let ABE with revocability, namely, direct
and indirect methods. The direct revocation requires the sender
to know the revocation list during the encryption process,
while the indirect revocation requires the non-revoked users to
update their private keys periodically. The advantage of direct
revocation over the indirect revocation is that the non-revoked
users do not need to update their private keys periodically.
On the opposite, the advantage of indirect over the direct
revocation is that the sender does not need to know the
revocation list. They combined both the advantage of direct
and indirect revocation methods and proposed the first hybrid
revocable ABE scheme. Later, the fully secure revocable ABE
were proposed in [30] and [31]. They used composite order
bilinear groups to achieve fully secure which is less efficient
than the prime order bilinear groups. However, in our proposal,
we only need to issue a new security device to revoke the old
key without updating all other security devices, and we do not
need to maintain a revocation list for all the revoked security
devices. As a result, we believe that our scheme provides
an alternative approach to tackle the long-existed revocability
problem of ABE.
Another cryptographic privilege supporting revocability
is proxy re-encryption (PRE) which was proposed by
Blaze et al. in [32]. In a proxy re-encryption scheme, a proxy
(e.g Cloud which is semi-trusted) can transform a ciphertext
for a user into another ciphertext that another user can decrypt
while the proxy can learn nothing but the length of the
ciphertext. PRE can be formalized into two categories in
terms of the direction of transformation: bidirectional and
unidirectional. In bidirectional PRE, the proxy can transform
the ciphertext from one user into another user and vice versa.
In unidirectional PRE, the proxy can only convert in one
direction. To increase the efficiency and security of PRE, many
schemes were proposed [33]–[37]. We state that combining the
ABE and PRE techniques, the resulting solution still cannot
satisfy the desired requirements in the data sharing scenario
for cloud computing. In particular, it cannot support the
two-factor protection.
B. Organization
The remaining paper is organized as follows. In Section II,
we give the models and design goals for our scheme.
In Section III, we give the necessary background for our
assumption. After that, we present our fine-grained two-factor
data protection mechanism for cloud storage in Section IV
and its security analysis in Section V. We also give the
Fig. 1. Architecture of our framework.
Fig. 2. The process of SDK update.
performance evaluation for our scheme in VI. Finally, we give
the conclusion in Section VII.
II. F
RAMEWORK AND DESIGN GOAL
In this section, we formalize the system model and attack
models considered in this paper, and identify the design goals.
A. Framework Architecture
Fig. 1 shows the architecture of our CP-ABE based fine-
grained two-factor data protection framework. There are four
main entities in our framework: Central Authority (CA),
Cloud, Data Owners (DOs) and Data Receivers (DRs).
1
•
Central Authority (CA): A CA is a trusted party which
is responsible for issuing the cryptographic key for every
user according to their attribute set and then splitting it
into two parts (two-factor): One, called as Secret Part
Key (SPK), is assumed to be stored in a potential-insecure
place (e.g., computer). The other, named as Security
Device Key (SDK) is stored in a physically-secure but
computationally limited device (security device). Further-
more, CA is also responsible for updating every user’s
security device (and the corresponding SDK). Specially,
1
Both DOs and DRs are users.