31-10-2016, 11:27 AM
1462353405-15.KeyAggregateCryptosystemforScalable.pdf (Size: 880.21 KB / Downloads: 4)
Abstract—Data sharing is an important functionality in cloud storage. In this paper, we show how to securely, efficiently, and flexibly
share data with others in cloud storage. We describe new public-key cryptosystems that produce constant-size ciphertexts such that
efficient delegation of decryption rights for any set of ciphertexts are possible. The novelty is that one can aggregate any set of secret
keys and make them as compact as a single key, but encompassing the power of all the keys being aggregated. In other words, the
secret key holder can release a constant-size aggregate key for flexible choices of ciphertext set in cloud storage, but the other
encrypted files outside the set remain confidential. This compact aggregate key can be conveniently sent to others or be stored in a
smart card with very limited secure storage. We provide formal security analysis of our schemes in the standard model. We also
describe other application of our schemes. In particular, our schemes give the first public-key patient-controlled encryption for flexible
hierarchy, which was yet to be known.
INTRODUCTION
CLOUD storage is gaining popularity recently. In enterprise
settings, we see the rise in demand for data
outsourcing, which assists in the strategic management of
corporate data. It is also used as a core technology behind
many online services for personal applications. Nowadays,
it is easy to apply for free accounts for email, photo album,
file sharing and/or remote access, with storage size more
than 25 GB (or a few dollars for more than 1 TB). Together
with the current wireless technology, users can access
almost all of their files and emails by a mobile phone in any
corner of the world.
Considering data privacy, a traditional way to ensure it is
to rely on the server to enforce the access control after
authentication (e.g., [1]), which means any unexpected
privilege escalation will expose all data. In a shared-tenancy
cloud computing environment, things become even worse.
Data from different clients can be hosted on separate virtual
machines (VMs) but reside on a single physical machine.
Data in a target VM could be stolen by instantiating another
VM coresident with the target one [2]. Regarding availability
of files, there are a series of cryptographic schemes
which go as far as allowing a third-party auditor to check
the availability of files on behalf of the data owner without
leaking anything about the data [3], or without compromising
the data owners anonymity [4]. Likewise, cloud users
probably will not hold the strong belief that the cloud server
is doing a good job in terms of confidentiality. A cryptographic
solution, for example, [5], with proven security
relied on number-theoretic assumptions is more desirable,
whenever the user is not perfectly happy with trusting the
security of the VM or the honesty of the technical staff.
These users are motivated to encrypt their data with their
own keys before uploading them to the server.
Data sharing is an important functionality in cloud
storage. For example, bloggers can let their friends view a
subset of their private pictures; an enterprise may grant her
employees access to a portion of sensitive data. The
challenging problem is how to effectively share encrypted
data. Of course users can download the encrypted data
from the storage, decrypt them, then send them to others for
sharing, but it loses the value of cloud storage. Users should
be able to delegate the access rights of the sharing data to
others so that they can access these data from the server
directly. However, finding an efficient and secure way to
share partial data in cloud storage is not trivial. Below we
will take Dropbox1 as an example for illustration.
Assume that Alice puts all her private photos on
Dropbox, and she does not want to expose her photos to
everyone. Due to various data leakage possibility Alice
cannot feel relieved by just relying on the privacy protection
mechanisms provided by Dropbox, so she encrypts all the
photos using her own keys before uploading. One day,
Alice’s friend, Bob, asks her to share the photos taken over
all these years which Bob appeared in. Alice can then use
the share function of Dropbox, but the problem now is how
to delegate the decryption rights for these photos to Bob. A
possible option Alice can choose is to securely send Bob the secret keys involved. Naturally, there are two extreme ways
for her under the traditional encryption paradigm:
. Alice encrypts all files with a single encryption key
and gives Bob the corresponding secret key directly.
. Alice encrypts files with distinct keys and sends Bob
the corresponding secret keys.
Obviously, the first method is inadequate since all unchosen
data may be also leaked to Bob. For the second method,
there are practical concerns on efficiency. The number of
such keys is as many as the number of the shared photos,
say, a thousand. Transferring these secret keys inherently
requires a secure channel, and storing these keys requires
rather expensive secure storage. The costs and complexities
involved generally increase with the number of the
decryption keys to be shared. In short, it is very heavy
and costly to do that.
Encryption keys also come with two flavors—symmetric
key or asymmetric (public) key. Using symmetric encryption,
when Alice wants the data to be originated from a
third party, she has to give the encryptor her secret key;
obviously, this is not always desirable. By contrast, the
encryption key and decryption key are different in publickey
encryption. The use of public-key encryption gives
more flexibility for our applications. For example, in
enterprise settings, every employee can upload encrypted
data on the cloud storage server without the knowledge of
the company’s master-secret key.
Therefore, the best solution for the above problem is that
Alice encrypts files with distinct public-keys, but only sends
Bob a single (constant-size) decryption key. Since the
decryption key should be sent via a secure channel and
kept secret, small key size is always desirable. For example,
we cannot expect large storage for decryption keys in the
resource-constraint devices like smart phones, smart cards,
or wireless sensor nodes. Especially, these secret keys are
usually stored in the tamper-proof memory, which is
relatively expensive. The present research efforts mainly
focus on minimizing the communication requirements
(such as bandwidth, rounds of communication) like
aggregate signature [6]. However, not much has been done
about the key itself (see Section 3 for more details).
1.1 Our Contributions
In modern cryptography, a fundamental problem we often
study is about leveraging the secrecy of a small piece of
knowledge into the ability to perform cryptographic
functions (e.g., encryption, authentication) multiple times.
In this paper, we study how to make a decryption key more
powerful in the sense that it allows decryption of multiple
ciphertexts, without increasing its size. Specifically, our
problem statement is
“To design an efficient public-key encryption scheme which
supports flexible delegation in the sense that any subset of the
ciphertexts (produced by the encryption scheme) is decryptable by
a constant-size decryption key (generated by the owner of the
master-secret key).”
We solve this problem by introducing a special type of
public-key encryption which we call key-aggregate cryptosystem
(KAC). In KAC, users encrypt a message not
only under a public-key, but also under an identifier of ciphertext called class. That means the ciphertexts are
further categorized into different classes. The key owner
holds a master-secret called master-secret key, which can be
used to extract secret keys for different classes. More
importantly, the extracted key have can be an aggregate key
which is as compact as a secret key for a single class, but
aggregates the power of many such keys, i.e., the decryption
power for any subset of ciphertext classes.
With our solution, Alice can simply send Bob a single
aggregate key via a secure e-mail. Bob can download
the encrypted photos from Alice’s Dropbox space and then
use this aggregate key to decrypt these encrypted photos.
The scenario is depicted in Fig. 1.
The sizes of ciphertext, public-key, master-secret key,
and aggregate key in our KAC schemes are all of constant
size. The public system parameter has size linear in the
number of ciphertext classes, but only a small part of it is
needed each time and it can be fetched on demand from
large (but nonconfidential) cloud storage.
Previous results may achieve a similar property featuring
a constant-size decryption key, but the classes need to
conform to some predefined hierarchical relationship. Our
work is flexible in the sense that this constraint is
eliminated, that is, no special relation is required between
the classes. The detail and other related works can be found
in Section 3.
We propose several concrete KAC schemes with different
security levels and extensions in this paper. All constructions
can be proven secure in the standard model. To the
best of our knowledge, our aggregation mechanism2 in KAC
has not been investigated.
KEY-AGGREGATE ENCRYPTION
We first give the framework and definition for keyaggregate
encryption. Then we describe how to use KAC
in a scenario of its application in cloud storage.