Cloud
Service Provier
Storage Node
User
Region
Server
Region
Server
Storage Node
1
2
3
3
Region 1
Region 2
3
3
(a) Registration Stage
Cloud
Service Provider
Storage Node
User
Region Server
Region Server
Storage Node
1
2
Region 1
Region 2
3
3
(b) Storage Stage
Cloud
Service Provider
Storage Node
User
Region Server
Region Server
Storage Node
1
2
Region 1
Region 2
5
4
6
3
(c) Retrieval Stage
Figure 1: Stages in SecLoc
4.1 Design Goals and Threat Model
In our work, we consider three types of entities:
• Cloud service providers: This includes cloud vendors
and their storage nodes. Storage nodes may be located
in different regions and are uniquely identifiable by
their cloud vendor.
• Cloud users: Cloud users mainly refer to the users
who use the cloud storage services. They may have
specific requirements on which regions are allowed to
store their data and only the storage nodes located in
these regions can process their data.
• Region servers: These servers are independent of the
cloud service providers. Each server is in charge of a
region and responsible for authenticating the storage
nodes in its controlled regions.
The overarching goal of the SecLoc framework is to pre-
vent storage nodes outside the user specified regions from
accessing the content of the user data. More specifically,
the SecLoc framework has the following unique features:
• Location-sensitive access control: The cloud user’s data
will only be accessible to the cloud storage nodes that
satisfy user specified location constraints. Storage nodes
outside the expected regions will not be able to obtain
the plaintext of the user data.
• Content-based access control : Even the storage nodes
assigned to store the user data will only be given access
to the content of the data that is allowed by the user
specified access control p olicies. For example, users
can store fully encrypted data at the storage node and
the storage node will only be able to compute the de-
cryption key for only a portion of the data that is
allowed to be processed.
• Keyless: Unlike many traditional key-based security
[5], cloud users in our SecLoc system do not need to
maintain a large number of keys, which helps avoid the
potential risk of key leakage or abuse.
• Cost effectiveness: Our proposed SecLoc system in-
troduces minimum overhead on top of existing cloud
storage services, which will ensure its wide adoption in
the real world applications.
The SecLoc framework is developed based on the following
assumptions and threat model. First, we assume that the
cloud storage architecture is static, and each storage node in
this architecture is globally identifiable. Second, we assume
that the region servers are developed as a minimally trusted
third-party service. By minimally trusted, we mean that
the region servers are able to reliably authenticate the stor-
age nodes in their controlled regions so long as they are not
compromised by attackers. Third, we do not trust the cloud
service providers and their storage nodes, either of which
could b e compromised to extract user’s (encrypted) data.
Fourth, we assume that the storage nodes and region servers
in the same region will not be compromised simultaneously.
We argue that this assumption is realistic, because the stor-
age nodes (belonging to cloud service providers) and region
servers are maintained by different parties, and it rarely oc-
curs when multiple parties’ servers are compromised by the
same attacker at the same time.
Under the above threat model, we consider two types of
attacks: 1) The cloud service provider might provide a tam-
pered list of candidate nodes to the user, misleading the user
to store data in a wrong place; 2) The storage nodes might
collude with each other, or even with some compromised
region servers, to extract user’s (encrypted) data.
4.2 SecLoc Framework
We now give an overview of our proposed Secure Location-
sensitive (SecLoc) storage framework. The SecLoc consists
of three stages:
• Registration Stage. This stage generates system pa-
rameters and assignments. As shown in Figure 1(a),
initially the user requests a storage service from the
cloud service provider (highlighted by workflow 1 in
Figure 1(a)). The cloud service provider assigns sev-
eral storage nodes for this requested service and re-
turns the list of candidate storage nodes to the user
(highlighted by workflow 2 in Figure 1(a)). Note that
these candidate storage nodes may be located in differ-
ent regions and they are just a small subset of storage
nodes maintained by the cloud service provider. Any
tamper to the list of candidate nodes can be easily
prevented using public key infrastructure whereby the
list can be encrypted with the user’s public key and
opened by the user using the corresponding secret key.
After receiving the list of the candidate storage nodes,
the user will verify the location of the storage nodes