before it is sent to the cloud; a data verifier (DV), that checks whether the data in the cloud has
been tampered with; and a token generator (TG), that generates tokens that enable the cloud
storage provider to retrieve segments of customer data; and a credential generator that implements
an access control policy by issuing credentials to the various parties in the system (these credentials
will enable the parties to decrypt encrypted files according to the policy). We describe designs for
both consumer and enterprise scenarios.
2.1 A Consumer Architecture
Consider three parties: a user Alice that stores her data in the cloud; a user Bob with whom Alice
wants to share data; and a cloud storage provider that stores Alice’s data. To use the service, Alice
and Bob begin by downloading a client application that consists of a data processor, a data verifier
and a token generator. Upon its first execution, Alice’s application generates a cryptographic key.
We will refer to this key as a master key and assume it is stored locally on Alice’s system and that
it is kept secret from the cloud storage provider.
Whenever Alice wishes to upload data to the cloud, the data processor is invoked. It attaches
some metadata (e.g., current time, size, keywords etc) and encrypts and encodes the data and
metadata with a variety of cryptographic primitives (which we describe in more detail in Section
4). Whenever Alice wants to verify the integrity of her data, the data verifier is invoked. The
latter uses Alice’s master key to interact with the cloud storage provider and ascertain the integrity
of the data. When Alice wants to retrieve data (e.g., all files tagged with keyword “urgent”) the
token generator is invoked to create a token. The token is sent to the cloud storage provider who
uses it to retrieve the appropriate (encrypted) files which it returns to Alice. Alice then uses the
decryption key to decrypt the files. Data sharing between Alice and Bob proceeds in a similar
fashion. Whenever she wishes to share data with Bob, the application invokes the token generator
to create an appropriate token, and the credential generator to generate a credential for Bob. Both
the token and credential are sent to Bob who, in turn, sends the token to the provider. The latter
uses the token to retrieve and return the appropriate encrypted documents which Bob decrypts
using his credential.
This process is illustrated in Figure 1. We note that in order to achieve the security properties
we seek, it is important that the client-side application and, in particular, the core components be
either open-source or implemented or verified by someone other than the cloud service provider.
2.2 An Enterprise Architecture
In the enterprise scenario we consider an enterprise MegaCorp that stores its data in the cloud;
a business partner PartnerCorp with whom MegaCorp wants to share data; and a cloud storage
provider that stores MegaCorp’s data.
To use the service, MegaCorp deploys dedicated machines within its network. Depending on
the particular scenario, these dedicated machines will run various core components. Since these
components make use of a master secret key, it is important that they be adequately protected and,
in particular, that the master key be kept secret from the cloud storage provider and PartnerCorp.
If this is too costly in terms of resources or expertise, management of the dedicated machines (or
specific components) can alternatively be outsourced to a trusted entity.
In the case of a medium-sized enterprise with enough resources and expertise, the dedicated
machines include a data processor, a data verifier, a token generator and a credential generator.
3