24-06-2014, 03:46 PM
Reliable Re-encryption in Unreliable Clouds
Reliable Re-encryption.pdf (Size: 141.8 KB / Downloads: 38)
Abstract
—A key approach to secure cloud computing is for
the data owner to store encrypted data in the cloud, and issue
decryption keys to authorized users. Then, when a user is
revoked, the data owner will issue re-encryption commands to
the cloud to re-encrypt the data, to prevent the revoked user
from decrypting the data, and to generate new decryption keys to
valid users, so that they can continue to access the data. However,
since a cloud computing environment is comprised of many cloud
servers, such commands may not be received and executed by all
of the cloud servers due to unreliable network communications.
In this paper, we solve this problem by proposing a timebased
re-encryption scheme, which enables the cloud servers to
automatically re-encrypt data based on their internal clocks. Our
solution is built on top of a new encryption scheme, attributebased
encryption, to allow fine-grain access control, and does not
require perfect clock synchronization for correctness.
Index Terms—Attribute-based encryption, cloud computing
INTRODUCTION
The use of cloud computing is increasingly popular due to
the potential cost savings from outsourcing data to the cloud
service provider (CSP). One technique to protect the data from
a possible untrusted CSP is for the data owner to encrypt the
outsourced data [1], [2]. Flexible encryption schemes such as
attribute based encryption (ABE) [3]–[5] can be adopted to
provide fine grained access control.
ABE allows data to be encrypted using an access structure
comprised of different attributes. Instead of specific decryption
keys for specific files, users are issued attribute keys. Users
must have the necessary attributes that satisfy the access structure
in order to decrypt a file. For example, a file encrypted
using the access structure {(1 ∧ 2) ∨ 3} means that either
a user with attributes 1 and 2, or a user with attribute 3,
can decrypt the file.
The key problem of storing encrypted data in the cloud lies
in revoking access rights from users. A user whose permission
is revoked will still retain the keys issued earlier, and thus
can still decrypt data in the cloud. A na¨ıve solution is to let
the data owner immediately re-encrypt the data, so that the
revoked users cannot decrypt the data using their old keys,
while distributing the new keys to the remaining authorized
users. This solution will lead to a performance bottleneck,
especially when there are frequent user revocations.
An alternative solution is to apply the proxy re-encryption
(PRE) technique [6], [7]. This approach takes advantage of
the abundant resources in a cloud by delegating the cloud to
re-encrypt data [8], [9]. This approach is also called command-
BASIC R3
In the basic R3 scheme, we consider ideal conditions, where
the data owner and all of the cloud servers in the cloud
share a synchronized clock, and there are no transmission and
queueing delays when executing read and write commands.
A. Intuition
The data owner will first generate a shared secret key to the
CSP. Then, after the data owner encrypts each file with the
appropriate attribute structure and time slice, the data owner
uploads the file in the cloud. The CSP will replicate the file
to various cloud servers. Each cloud server will have a copy
of the shared secret key.
Let us assume that a cloud server stores an encrypted file
F with A and TSi. When a user queries that cloud server, the
cloud server first uses its own clock to determine the current
time slice. Assuming that the current time slice is TSi+k,
the cloud server will automatically re-encrypt F with TSi+k
without receiving any command from the data owner. During
the process, the cloud server cannot gain the contents of the
cipertext and the new decryption keys. Only users with keys
satisfying A and TSi+k will be able to decrypt F.
B. Protocol Description
We divide the description of the basic R3 scheme into three
components: data owner initialization, data user read data and
data owner write data. We will rely on the following functions.
Table II shows the notations used in the description.
ADDITIONAL DISCUSSION
One concern with the R3 scheme design is that associating
a different ciphertext for every time slice will require users
to manage a lot of keys. The number of keys that the R3
scheme requires is related to the actual length of the time
slice. This length can be set according to different application
requirements. Thus, an application that expects to revoke users
on a monthly basis will have a longer time slice, and hence
have far fewer keys, than an application where membership
changes by the hour. Furthermore, issuing multiple keys upfront
is actually more efficient. Consider an alternative design
where each valid user was issued just one key. Now, every
time any user is revoked, the owner has to inform the CSP to
re-encrypt the previous ciphertext so as to prevent the revoked
user from decrypting it again. The owner then has to update
all of the remaining valid users with the new keys to allow
them to decrypt the new ciphertext. We argue that any scheme
that stores encrypted data in the cloud has to deal with the
issue of re-encryption and re-keying. Since the remaining users
may not be online all of the time, the re-keying process is
arguably more costly. A possible improvement is to let the
owner issue a valid user a special seed value which the user
can then use to generate keys on his own. The challenge here
is to prevent the user from generating additional keys beyond
what is authorized. This remains part of our future research.
Furthermore, we only let the data owner perform data
updates. This is inflexible for applications where users may
need to update the data as well. Our solution can be extended
to allow users to perform data updates in addition to data
owners. A ticketing scheme can be used. The data owner will
issue and sign a timestamp to authorize the user to perform a
write. The user will submit the ticket together with his updates
to the CSP, which will then apply the updates. The challenge
here is the time lag between when the data owner issues the
ticket and when the user’s request reaches the CSP. This time
lag may be unknown since the user may delay sending his
update to the cloud. An additional protocol will be required
to allow the CSP to reject update requests that are too close
to the time slice borders.
VII. CONCLUSION
In this paper, we proposed the R3 scheme, a new method for
managing access control based on the cloud server’s internal
clock. Our technique does not rely on the cloud to reliably
propagate re-encryption commands to all servers to ensure
access control correctness. We showed that our solutions
remain secure without perfect clock synchronization so long
as we can bound the time difference between the servers and
the data owner.