Cloud and the Law

Encryption- Cloud federation is the practice of

interconnecting public and private
cloud services from two or more
providers to extend the scalability

Based Solution of existing cloud systems, increase

elasticity in resource management,
and accommodate spikes in demand.
Because workloads are outsourced to cost-effective

for Data regions, cloud federation can also potentially result

in significant cost savings (electricity, hardware pro-
visioning, and so on). This outsourcing also allows
federated clouds to overcome emerging challenges,

Sovereignty such as big data handling/disaster recovery through

colocation and geographic distribution of computing
and storage resources, together with other methods.
Therefore, it isn’t surprising that cloud federa-

in Federated tion is an increasingly popular option for both users

and providers (for example, Google’s InterCloud). A
Gartner study, for example, forecasts that through
2020, hybrid clouds will overtake both public and

Clouds private cloud services to be the dominant cloud ser-

vice model.1
To provide service aggregation, seamlessly
and transparently integrating public and private
cloud services from two or more providers is criti-
cal. These services will likely have been built us-
ing different infrastructures. For example, one will
need to resolve heterogeneity-related issues at the
infrastructure level (for example, exchanged data
Christian Esposito formats, interfaces of provided services, and com-
University
munication means), and ensure that other (nontech-
of Napoli “Federico II”
nical) issues, such as differing resource allocation
policies, economic models, and management poli-
cies, won’t affect the federated cloud’s smooth op-
eration. Various initiatives have sought to identify
Aniello Castiglione and promote open solutions and standards for cloud
University of Salerno interoperability. Examples include the Open Cloud
Manifesto (www.opencloudmanifesto.org), Open
Cloud Computing Interface (OCCI, http://occi-wg
.org), Open Cloud Standards Incubator (http://www
.dmtf.org/standards/cloud), and Cloud Data Man-
Kim-Kwang agement Interface (CDMI, www.snia.org/cdmi).
Raymond Choo Cloud federation has also been the focus of recent
University research efforts. For example, several researchers
of South Australia have proposed middleware abstraction layers to fa-
cilitate cloud federation2 (see Figure 1).
As the figure illustrates, a front-end is provid-
ed for interactions with cloud service consumers.

12 I E E E C l o u d C o m p u t i n g p u b l i s h e d b y t h e I E E E c o m p u t e r s o cie t y  2325-6095/16/$33.00 © 2016 IEEE

 Cloud federation

Cloud A Cloud B Cloud C

Consumer

Federation middleware

Integration layer Allows the communication

of each cloud to/from the
Cloud orchestration solution.
service Embodies the orchestration
brokerage logic for the interconnection
Orchestration layer of clouds.

Represents the
front-end of the
cloud federation

Figure 1. A generic federation middleware for clouds can be schematically viewed as composed of two
different abstraction layers: one providing communication capabilities, the other offering orchestration
means.

This component hides the federation’s complexity,
so from the consumers’ perspective, the service ap-
pears to be running on a single cloud platform. An
integration layer enforces the interoperability among
heterogeneous cloud platforms. An orchestration
layer, built on top of the integration layer, harmoniz-
es the different management strategies and models
of the federated clouds.
Challenges
In addition to the interoperability issues, a federated
cloud service faces security and legal challenges.
Cloud consumers’ concerns about the lack of con-
trol over the outsourced data and computational
activities, and about data being stored in multiple
disparate datacenters located in different countries,
are exacerbated in a federated cloud environment,
where, to maximize efficient resource utilization,
automated software within the federation middle-
ware can replicate and/or move data between differ-
ent cloud services and datacenters, possibly located
in different countries.
These activities can take place without the
data owner’s knowledge or informed consent. For
example, in the case of private clouds, the data
owner must have given consent by specifying geo-
graphical, legislative, and data location constraints
in the service-level agreement (SLA), whereas in a
public cloud, such a requirement might not be pres-
ent in the SLA. In both cases, the federated cloud
service providers (CSPs) might not even be able
to determine the “split” data’s exact location. This
could potentially result in organizations breaching
the exacting privacy and other regulations in the ju-
risdiction in which they operate. More specifically,
consumer data is managed by a CSP regulated un-
der a legal framework that might be inconsistent or
conflict with that of the data owner, and data can be

J a n u a r y/ F e b r u a r y 2 0 1 6 I EEE Clo u d Co m p u t i n g 13
 Cloud and the Law
accessed by users from countries with privacy rules
that are inconsistent (or conflict) with those of the
data owner.
Therefore, establishing data sovereignty3 (that
is, controlling and verifying the data’s geoloca-
tion) is of pivotal importance when (federated)
cloud services are used to store sensitive data to
ensure that data stored in the cloud won’t be avail-
able to anyone in a location with a conflicting
legal framework (for example, data about the US
transport-critical infrastructure shouldn’t be stored
or made available to anyone located outside the
country, particularly in US Office of Foreign Assets
Restrictions on data storage and
access can also differ among states
within the same country, or between
countries.
Control [OFAC] sanctioned countries).4 Ensuring
data sovereignty can be part of the SLA manage-
ment system. Existing research on this topic has
two general focus areas:
• imposing geolocation and legislation awareness
policies when locating data within the cloud in-
frastructure,5 and
• verifying the compliance of SLA policies when
storing data in a cloud infrastructure.6
In the first case, data can’t be moved around
the cloud infrastructure, and the CSP can’t apply
its internal strategies to improve storage and re-
trieval efficiency. In the second case, there’s no as-
surance that the data has been duplicated and the
copies moved to other locations, hence violating
SLA policies. In both cases, the data owner must
trust the CSP to be doing the right thing; however,
such blind trust makes the data stored in the cloud
vulnerable because of the possibility of a mali-
cious or corrupt insider/CSP. This is evidenced in
14 I EEE Clo u d Co m p u t i n g w w w.co m p u t er .o rg /clo u d co m p u t i n g
the recent high-profile incident involving Edward
Snowden.
When using a cloud federation, consumers
don’t know the data’s exact location (for example,
which datacenter in which country the data will
be stored). In fact, the cloud federation’s front end
is represented by a broker service that receives a
consumer’s request and decides how to allocate
the hardware commodity, based on predefined se-
lection algorithms7 without the consumer or data
owner’s involvement. Moreover, the data owner
can share access to outsourced data with other
consumers, as long as they have Internet connec-
tivity, even if they’re located in a dif-
ferent geographic location. These are
serious issues when handling sensitive
data,8 such as healthcare data, bio-
medical datasets, or financial informa-
tion. Access to this data is generally
governed by various legal restrictions,
such as the Health Insurance Porta-
bility and Accountability Act (HIPAA)
and Control Objectives for Informa-
tion and Related Technology (COBIT).
For example, the European Union
(EU) Data Protection Directive states
that any personal data generated within the EU
is subject to European law and data can only be
shared with a third party if the owner is notified.9
However, the data can’t leave the EU unless the
third party is located in a country that provides an
adequate level of protection, for example, coun-
tries that participate in the Safe Harbor program
(www.export.gov/safeharbor).
As noted elsewhere, “It is a near impossible
task to fully harmonise privacy and data protec-
tion regimes due to the different judicial and legal
systems internationally. There are countries that
do not have any mandatory data retention or data
protection requirements.”10 In other words, restric-
tions on data storage and access can also differ
among states within the same country, or between
countries. Within the EU, countries such as France
and Denmark have broad restrictions, but coun-
tries such as Italy and Germany have limited or no
restrictions for certain types of data.11 CSPs with
an international presence will have to comply with
a myriad of regulatory obligations, both domes-
tic and international. For example, in the United
States, the Patriot Act allows US intelligence agen-
cies to access personal data managed by US compa-
nies without notifying the data owners, in an effort
to enhance domestic security by surveying suspect-
ed terrorists.12
The EU directive and the US Patriot Act have
conflicting requirements in relation to disclosure re-
quirements. US CSPs operating in the EU must com-
ply with US legislation (such as the Patriot Act) in
addition to EU data protection and notification laws.
In other words, US CSPs could be criminally liable or
subject to prosecution in the EU should they release
EU citizens’ data to the US Government
under the US Patriot Act without notify-
ing the data owner.
Naïve solutions for cloud federation
include deploying only cloud services
from domestic providers or providers lo-
cated in countries with compatible legal
requirements, or defining geographical
boundaries for data storage and move-
ment. The latter can be achieved by
implementing restriction policies within
the SLA. When a cloud consumer sub-
mits a request to the cloud through a
broker service, the service can consider geolocation
restrictions when selecting the best datacenter, and/
or the right federated cloud, to host the consumer
data. Based on an adequately secure verification
mechanism (such as an SLA management system
that observes the runtime performance of cloud ser-
vices and aggregates the observed data into SLA re-
porting metrics13), the cloud consumer can validate
whether the conditions outlined in the SLA have
been satisfied or fulfilled.
Zachary Peterson and his colleagues identify a
possible solution to achieving data sovereignty us-
ing proof of data possession (PDP).3 PDP proves
the existence of certain data outsourced to a cloud
server, and the proof can be used to test the data’s
retrievability from an untrusted cloud server (for
this reason, PDP is also known as proof of retriev-
ability). However, existing proposed proofs of loca-
tion schemes have limitations:
• the use of landmarks complicates the practical
implementation of such schemes;
J a n u a r y/ F e b r u a r y 2 0 1 6 I EEE Clo u d Co m p u t i n g
• the schemes might not consider the verification
of possible copies of data of interest (this isn’t
uncommon in cloud computing because of per-
formance and availability); and
• geolocation accuracy depends on timing delays
and packet losses.
Moreover, naïve solutions mandating the use
of domestic CSPs and having geographical re-
strictions provide a false sense of security since
a malicious or corrupt CSP can circumvent such
restrictions prior to the consumer undertaking any
SLA verification.
Naïve solutions mandating the
use of domestic CSPs and having
geographical restrictions provide a
false sense of security.
Potential Solution
Data geolocation or domestic CSP restrictions will
also undermine the benefits of cloud federation.
Therefore, we posit that a simpler solution is to adopt
an encryption-at-rest approach in a federated cloud,
where consumers control the cryptographic keys.
Several CSPs provide encryption for data at rest as a
privacy guarantee, allowing users to keep some con-
trol of their own data, and not allowing CSPs, be-
lieved to be untrustworthy, to access the outsourced
data. This removes the urge to know where the data
is located or which legal framework to apply for data
outsourced to the cloud, since only those who pos-
sess the decryption key can access the outsourced
data.14 Moreover, even if transferred to a different
country from that of the data owner, the outsourced
data isn’t subject to foreign law since CSPs can’t be
forced to provide data to which it has no access.
Figure 2 shows a potential implementation of
this solution. The data owner (User 1) specifies the
desired geographic location within which his or her
data may be disclosed. Based on this geolocation
15
 Cloud and the Law

User 2’s data User 2’s

consumer geolocation
Encrypted data
Encrypted data
Decryption
algorithm Decryption key

Plaintext Decrypted data

data
User 1
Encryption
data owner
algorithm
Cloud federation Error

Encrypted data
Decryption key
Geolock
Geolocation encryption key
requirement Decryption
algorithm

User 3’s
geolocation
User 3’s data
consumer

Figure 2. An encryption-based solution for data sovereignty in federated clouds can include an encryption stage done by the
data owners, and decryption stages done by data consumers that have retrieved the encrypted data from different clouds than
the one of the data owner.

requirement, an encryption key is constructed and Data sovereignty is a key require-

the data to be outsourced is encrypted and loaded
into the cloud federation. A set of data consum-
ers may retrieve the encrypted data from the cloud
federation. We can have two classes of consumers:
those in a location that satisfies the data owner’s
requirement (User 2), and those outside the data
owner’s desired geographic location (User 3). Both
users construct a decryption key from their current
location, but only User 2 can obtain the plaintext of
the retrieved data, while the other fails.
In such a solution, a key problem is to design
a mechanism that can securely determine a user’s
location. Such a mechanism must be equipped with
techniques to protect itself from a malicious user
providing false information to mark the user’s true
location. Such a geolocation spoofing attack can
be neutralized using techniques discussed in the
literature.15
ment for outsourcing sensitive data
in the cloud, particularly in privacy-
conscious jurisdictions such as
countries within the European Union.
This column proposed enforcing geolocation control
using encryption, rather than the traditional solu-
tion of limiting the placement of data within certain
geographic areas.
References
1. “Hype Cycle for Emerging Technologies,” Gartner,
2012; www.gartner.com/DisplayDocument?doc cd
=233931.
2. C. Esposito et al., “Interconnecting Federated
Clouds by Using Publish-Subscribe Service,”
Cluster Computing, vol. 16, no. 4, 2013, pp.
887–903.
3. Z.N.J. Peterson, M. Gondree, and R. Beverly, “A

16 I EEE Clo u d Co m p u t i n g w w w.co m p u t er .o rg /clo u d co m p u t i n g

 Position Paper on Data Sovereignty: The Impor-
tance of Geolocating Data in the Cloud,” Proc.
3rd USENIX Conf. Hot Topics in Cloud Comput-
ing (HotCloud), 2011; www.usenix.org/legacy/
event/hotcloud11/tech/final_files/Peterson.pdf.
4. A.N. Toosi, R.N. Calheiros, and R. Buyya, “In-
terconnected Cloud Computing Environments:
Challenges, Taxonomy, and Survey,” ACM Com-
puting Surveys, vol. 47, no. 1, 2014, article 7.
5. N. Paladi, M. Aslam, and C. Gehrmann, “Trust-
ed Geolocation-Aware Data Placement in Infra-
structure Clouds,” Proc. IEEE 13th Int’l Conf.
Trust, Security and Privacy in Computing and
Comm. (TrustCom), 2014, pp. 352–360.
6. D.L. Fu, X.G. Peng, and Y.L. Yang, “Trusted Vali-
dation for Geolocation of Cloud Data,” Computer
J., vol. 58, no. 10, 2015, pp. 2595–2607.
7. C. Esposito et al., “Smart Cloud Storage Ser-
vice Selection Based on Fuzzy Logic, Theory
of Evidence and Game Theory,” IEEE Trans.
Computers, preprint Jan. 2015; doi:10.1109/
TC.2015.2389952.
8. A. Castiglione et al., “Cloud-Based Adaptive
Compression and Secure Management Services
for 3D Healthcare Data,” Future Generation
Computer Systems, vols. 43–44, Feb. 2015, pp.
120–134.
9. Directive 95/46/EC on the Protection of Individ-
uals with Regard to the Processing of Personal
Data and on the Free Movement of Such Data,
European Parliament and the Council, 24 Oct.
1995; http://eur-lex.europa.eu/legal-content/EN/
TXT/HTML/?uri=CELEX:31995L0046.
10. K.-K.R. Choo, “Cloud Computing: Challenges
and Future Directions,” Trends & Issues in Crime
and Criminal Justice, no. 400, Oct. 2010, pp.
1–6.
11. EU Country Guide Data Location & Access Re-
striction. A Brief Survey, De Brauw Blackstone
Westbroek, Jan. 2013; www.verwal.net/wp/wp
-content/uploads/2014/03/EU-Country-Guide
-Data-Location-and-Access-Restrictions.pdf.
12. H.R. 3162, Uniting and Strengthening America
by Providing Appropriate Tools Required to In-
tercept and Obstruct Terrorism (US Patriot Act)
Act of 2001, US Govt. Printing Office, Jan. 2001;
www.gpo.gov/fdsys/pkg/BILLS-107hr3162enr/
pdf/BILLS-107hr3162enr.pdf.
J a n u a r y/ F e b r u a r y 2 0 1 6 I EEE Clo u d Co m p u t i n g
13. P. Bhoja, S. Singhalb, and S. Chutanic, “SLA
Management in Federated Environments,” Com-
puter Networks, vol. 35, no. 1, 2001, pp. 5–24.
14. S. Kamara and K. Lauter, “Cryptographic Cloud
Storage,” Financial Cryptography and Data Secu-
rity, R. Sion et al., eds., LNCS 6054, Springer,
2010, pp. 136–149.
15. J.A. Muir and P.C.V. Oorschot, “Internet Geo-
location: Evasion and Counter Evasion,” ACM
Computing Surveys, vol. 42, no. 1, 2009, article 4.
Christian Esposito is an adjunct professor at
the University of Naples “Federico II,” Italy, and a re-
search fellow at the University of Salerno, Italy. His
research interests include information security and
reliability, middleware, and distributed systems. Es-
posito has a PhD in computer engineering from the
University of Naples “Federico II.” Contact him at
christian.esposito@dia.unisa.it.
Aniello Castiglione is an adjunct professor at
the University of Salerno, Italy, and at the University
of Naples “Federico II,” Italy. His research interests in-
clude security, communication networks, information
forensics and security, and applied cryptography. Cas-
tiglione has a PhD in computer science from the Uni-
versity of Salerno. He’s a member of IEEE and ACM.
Contact him at castiglione@ieee.org.
Kim-Kwang Raymond Choo is an associate
professor at the University of South Australia and vis-
iting expert at the Interpol Global Complex for In-
novation. His research interests include cyber and
information security and digital forensics. Choo
has a PhD in information security from Queensland
University of Technology, Australia. He’s a senior
member of IEEE. Contact him at raymond.choo
@fulbrightmail.org.
Selected CS articles and columns are also available
for free at http://ComputingNow.computer.org.
17