Security in Cloud Computing
Kazi Zunnurhain1, and Susan V. Vrbsky
2
Department of Computer Science
The University of Alabama [email protected]; [email protected]
Abstract - Cloud computing has been envisioned as the next
generation architecture of IT Enterprises. It offers great
potential to improve productivity and reduce costs. In contrast
to traditional solutions, where the IT services are under
proper physical, logical and personnel controls, cloud
computing moves the application software and databases to
large data centers, where the management of the data and
services may not be fully trustworthy. This unique attribute,
however, poses many new security challenges which have not
been well understood yet. In this paper we investigate some
prime security attacks on clouds: Wrapping attacks, Malware-
Injection attacks and Flooding attacks, and the accountability
needed due to these attacks. The focus of this paper is to
identify and describe these prime attacks with the goal of
providing theoretical solutions for individual problems and to
integrate these solutions.
Keywords: Cloud Security, Wrapping Attack, Flooding
Attack, Hypervisor, Accountable cloud.
1 Introduction
In the field of computation, there have been many
approaches for enhancing the parallelism and distribution of
resources for the advancement and acceleration of data
utilization. Data clusters, distributed database management
systems, data grids, and many other mechanisms have been
introduced. Cloud computing is currently emerging as a
mechanism for high level computation, as well as serving as a
storage system for resources. Clouds allow users to pay for
whatever resources they use, allowing users to increase or
decrease the amount of resources requested as needed.
Cloud servers can be used to motivate the initiation of a
business and ease its financial burden in terms of Capital
Expenditure and Operational Expenditure [10].
Cloud computing has been introduced as providing a
large framework that is beneficial for clients which utilize all
or some aspects of it. Cloud computing can be thought of as
composed of different layers, depending on the distribution
of the resources. In this view, the CPU, memory and other
hardware components reside at the bottom-most layer, called
the Infrastructure as a Service (IaaS) layer. The layer which
is responsible for hosting different environments for
customer specific services is the middle layer, known as the
Platform as the Service (PaaS) layer. Finally, the topmost
layer is the Software as a Service (SaaS) layer, where cloud
service accessing takes place through the Web service and
web browsers. Amazon EC2 is a well known example of
IaaS, Google App engine is an example of PaaS and
salesforce.com is an example of SaaS.
It is clear that cloud computing is the next step in the
evolution of on-demand information technology services and
products. The ancestors of cloud computing have existed for
a long time now, such as the following distributed systems:
AEC08, Con08, Fos04, Had08, IBM07c, Net06 and VCL04
etc. The term cloud computing became popular in October
2007 after the announcement of IBM’s and Google’s
collaboration on Loh07 and IBM07a, which was followed by
IBM’s announcement of the “Blue Cloud” effort.
Cloud security is a complex issue, involving the different
levels of the cloud, external and internal threats, and
responsibilities that are divided between the user, the provider
and even a third party. The focus of this paper is to identify
and describe prime security attacks on clouds. The remainder
of this paper is organized as follows. In Section II a short
introduction about cloud security is provided followed by
some specific cloud security issues and related work in
Section III. Then Section IV focuses on the root causes of
those security issues and approaches are presented in Section
V to solve these problems. Finally the conclusions are
presented with thoughts for our future work and
improvements in Section VI.
2 Introduction to cloud security
Security threats on cloud users are both external and
internal. Many of the external threats are similar to the threats
that large data centers have already faced. This security
concern responsibility is divided among the cloud users, the
cloud vendors and the third party vendor involved in
ensuring secure sensitive software or configurations.
If the application level security is the responsibility of the
cloud user, then the provider is responsible for the physical
security and also for enforcing external firewall policies.
Security for intermediate layers of the software stack is
shared between the user and the operator. The lower the
level of abstraction exposed to the user, the more
responsibility goes with it [18].
Besides the external security issues, the cloud does
possess some internal security issues as well. Cloud providers
must guard theft or denial-of-service attacks by users. In
other words, users need to be protected from each other.
Virtualization is the primary mechanism that today’s clouds
have adapted because of its powerful defense and protection
against most of the attempts by users to attack each other or
the underlying cloud infrastructure. However, not all the
resources are virtualized and not all virtualization
environments are bug free. Virtualization software contains
bugs that allow virtualized code to “break loose” to some
extent. Incorrect network virtualization may allow user code
access to sensitive portions of the provider’s infrastructure or
to the resources of others.
The cloud should also be protected from the provider. By
definition, the provider controls the bottom layer of the
software stack, which effectively circumvents most known
security techniques. The one important exception is the risk
of inadvertent data loss.
In addition, if any kind of failure occurs, it is not clear who is
the responsible party. A failure can occur for various reasons:
1) due to hardware, which is in the Infrastructure as a Service
layer of the cloud; 2) due to malware in software, which is in
the Software as a Service layer of the cloud; or 3) due to the
customer’s application running some kind of malicious code,
the malfunctioning of the customer’s applications or a third
party invading a client’s application by injecting bogus data.
Whatever the reason, a failure can result in a dispute between
the provider and the clients.
2.1 Cloud security issues and related works
In this section we depict some prominent security issues
in cloud computing today, along with the techniques applied
by adversaries to intrude in the cloud. Also presented are the
after effects when the intruder has made a successful
compilation of his/her malicious program and hampered the
regular functioning of the cloud system. We describe existing
solutions and their pitfalls. Our observations in this paper will
be specific to each issue rather than imposing security as a
whole.
2.1.1 Soap Messages
As web service (WS) technology is the mostly used
technology in the field of SOA in the Cloud, the WS-security
system should be rigid enough to optimize the security
attacks from different adversaries. Security attacks can
involve SOAP messages. SOAP is an XML based messaging
framework, used to exchange encoded information (e.g. web
service request and response) over a variety of protocols (e.g.
HTTP, SMTP, MIME). It allows a program running in one
system to call a program running in another system and it is
independent of any programming model[22].
As of now, two common attacks with SOAP messages are
the Denial of Service and Wrapping attack. In the latter one,
the wrapping element signature attack is the main picture for
WS-security in large data centers like a cloud or grid system.
So in that light, there are some IT companies who have
accomplished some tasks thus far to prevent their system
from such kinds of attacks. But even a company like Amazon
had weaknesses in the SOAP request validation component
in their EC2 (Elastic Compute Cloud), and thus, allowed
unprivileged actions to take place in the cloud on a victim’s
account.
We now present an example using Amazon Web Service
(AWS) [16] technology and its security. In the beginning,
while registering, the customer has to provide a Self-Signed
Certificate, and a randomly generated RSA to the AWS. If
not, then a publicly defined certificate can be sent to the
AWS with the signature. Here the AWS provides some
command line tools to search the virtual machine images
(AMI- Amazon Machine Images), to run those images, to
monitor them and finally terminate some of the AMIs. These
SOAP messages can be modified by the developers. The
SOAP Header contains two elements. One is the
BinarySecurityToken which contains the certificate
mentioned above. The second is the TimeStamp which will
contain the information of the creation and expiration of this
SOAP. If the SOAP message is transferred through an
unsecured layer, then the SOAP Body (inside the SOAP:
Envelope) as well as the TimeStamp inside the SOAP Header
needs to be signed. If the transport layer is secured then only
the TimeStamp needs to be signed.
Since the channel is protected by means of SSL/TLS by
default, this is largely an ineffective attack vector. Also, as the
EC2 Web services allow access via simple HTTP as well, a
passive attack would be sufficient to get in possession of such
a request. For a wrapping attack to be successful, the only
requirement here is that the bogus Body needs to have exactly
the same ID as the original one.
2.1.2 Multi-core OS systems
Factored operating systems (fos) are designed to address
the challenges found in systems, such as cloud computing
and many core systems, and can provide a framework from
which to consider cloud security. In reality there are several
classes of systems having similarities to fos: traditional
microkernels, distributed OS’s and cloud computing
infrastructure. Traditional microkernels include Mach [2] and
L4. Instead of simple exploitation of parallelism between
servers, fos seeks to distribute and parallelize within a server
for a single high level function [1]. The main motive of fos
was to compel the scalability, elasticity of demand, fault
tolerance and resolve difficulties in programming a large
system. For a large system like a cloud, an OS such as fos is
the perfect match to take care of all the above issues.
textfos
App1 App2
Hypervisor Hypervisor Hypervisor
core1 core2 core3 core1 core2 core3 core1 core2 core3
Network Switch Cloud Manager
Figure 1: Hypervisor and Network Switch executes
the scheduling where fos communicates with the Cloud
Manager to send scheduling command
In many a core multi processor system, the OS manages
and monitors the resources, and the scheduling task. So in the
case of scalability, an application is factored into a service,
then it is also factored in additional services to be distributed
between service specific servers or a group of servers. Figure
1 illustrates the fos system functionality.
As mentioned previously, the resources are managed by
the OS. So the cores are dynamically distributed and
allocated for each of the services between the servers. A
periodic message is monitored to verify if all the servers are
working soundly or not. If one of the messages is missing,
then a server fault is detected and a decision can be taken to
appoint a new server for that specific task.
Unlike early cloud and cluster systems, fos provides a
single system image to an application. This means that the
application interface is that of a single machine while the OS
implements this interface across several machines in the cloud.
Aspects of fos can be used to secure cloud systems in and is
discussed in Section V.
2.1.3 Securing Code, Control Flow and Image
Repositories
Each user in the cloud is provided with an instance of a
Virtual Machine (VM): an OS, application, etc. Virtual
Machine Introspection (VMI) was proposed in [3] to monitor
VMs together with Livewire, a prototype IDS that uses VMI
to monitor VMs. A monitoring library named XenAccess is
for a guest OS running on top of Xen that applies the VMI
and virtual disk monitoring capabilities to access the memory
state and disk activity of a target OS. These approaches
require that the system must be clean when monitoring is
started, which is a flaw and needs further investigation in
VMI.
Lares [6] is a framework that can control an application
running in an untrusted guest VM by inserting protected
hooks into the execution flow of a process to be monitored.
Since the guest OS needs to be modified on the fly to insert
hooks, this technique may not be applicable in some
customized OS.
All of these works have some flaws when security is
considered in a cloud. So encapsulation of the cloud system in
a secured environment is mandatory.
2.1.4 Accountability in clouds
Making the cloud accountable means that the cloud will
be trustable, reliable and customers will be satisfied with
their monthly or yearly charge for using the provider’s cloud.
In Section IV we discuss several types of attacks on clouds,
all of which have an impact on the accountability of a cloud.
In this section we describe some of the work that has been
done on accountability.
Trusted computing [19] is an approach to achieve some of
the characteristics mentioned above to make a cloud
accountable. Typically, it requires trusting the correctness of
large and complex codebases.
A simple yet remarkably powerful tool of selfish and
malicious participants in a distributed system is
"equivocation": making conflicting statements to others. A
small, trusted component is TrInc[20] which combats
equivocation in large, distributed systems. TrInc provides a
new primitive: unique, once-in-a-lifetime attestations. It is
practical, versatile, and easily applicable to a wide range of
distributed systems. Evaluation shows that TrInc eliminates
most of the trusted storage needed to implement append-only
memory and significantly reduces communication overhead in
PeerReview. Small and simple primitives comparable to TrInc
will be sufficient to make clouds more accountable.
2.2 Security issue causes
Next, we identify different kinds of attacks in a cloud: a)
Wrapping attack, b) Malware-Injection attack, c) Flooding
attack, and in the face of these attacks the need for
Accountability checking. We describe each of these prime
security issues in cloud systems and depict their root causes.
2.2.1 Wrapping attack problem
When a user makes a request from his VM through the
browser, the request is first directed to the web server. In this
server, a SOAP message is generated. This message contains
the structural information that will be exchanged between the
browser and server during the message passing.
Here the Body of the message contains the operation
information and, it is supposedly signed by a legitimate user
by appending the <KeyInfo> and reference signatures in the
SOAP Body as well as the SOAP security <Header>. The
SOAP header contains the SOAP Body. Figure 2 [10] shows
an ideal case of a SOAP message where the user is requesting
a file me.jpg.
Soap: Envelope
getFile
Soap: Body
ds:Reference
ds:SignedInfo
ds:Signature
wsse: Security
Soap: Header
URI=”#body”
name=”me.jpg”
Id=”body”
Figure 2: SOAP message before attack [10]
For a wrapping attack, the adversary does its deception
before the translation of the SOAP message in the TLS
(Transport Layer Service) layer. If the Body is included with
a new Wrapper element inside the SOAP Header, then a
simple validation can easily disclose the original SOAP
message. Using this privilege an adversary makes a
duplication of the message, as in Figure 3 [10], and sends it
to the server as a legitimate user. The basic function for the
attacker is to wrap the total message in a new header, the
<Wrapper> element. Then the wrapper contains the original
message body, which is the legitimate request from the user,
and makes the <Security> as the new header element for that
message. So when the validation session takes place, the
server checks the authentication by the ID and integrity
checking for the message. The Bogus elements and its
contents are ignored by the recipient since this header is
unknown, but the signature is still acceptable because the
element at reference URI matches the same value as in the
wrapper element.
There are other ways to detect a security breach through
Wrapping. As discovered by Schaad and Rits, the inline
approach [9] is one of them. There are some protected
properties:
Number of child elements of SOAP: Envelope
Number of header elements inside Header
Successor and Predecessor of each signed object
Soap: Envelope
getFile
Soap: Body
ds:Reference
ds:SignedInfo
ds:Signature
wsse: Security
Soap: Header
URI=”#body”
name=”cv.doc”
Id=”bogus”
sellStocks
Soap: Body
Wrapper
Id=”body”
Name=”me.jpg”
Figure 3: SOAP message after attack [5]
If an attacker changes the structure of the message and
one of these properties is modified, the attack can be
detected. This approach is known as schema validation. In
this approach, the WS-Policy standardization will be adapted
in the SOAP validation and the properties mentioned above
will be injected as the SOAP header.
Since cloud computing is a new area in the field of SOA, it
is anticipated these approaches to verify the SOAP message
will experience many more obstacles.
2.2.2 Malware-injection attack problem
In the cloud system, as the client’s request is executed
based on authentication and authorization, there is a huge
possibility of meta data exchange between the web server and
web browser. An attacker can take advantage during this
exchange of metadata. Either the adversary makes his own
instance or the adversary may try to intrude with malicious
code. In this case, either the injected malicious service or
code appears as one of the valid instance services running in
the cloud. If the attacker is successful, then the cloud service
will suffer from eavesdropping and deadlocks, which forces a
legitimate user to wait until the completion of a job which was
not generated by the user. This type of attack is also known as
a meta-data spoofing attack.
2.2.3 Flooding attack problem
In a cloud system, all the computational servers work in a
service specific manner, with internal communication
between them. Whenever a server is overloaded or has
reached the threshold limit, it transfers some of its jobs to a
nearest and similar service-specific server to offload itself.
This sharing approach makes the cloud more efficient and
faster executing requests.
When an adversary has achieved the authorization to
make a request to the cloud, then he/she can easily create
bogus data and pose these requests to the cloud server. When
processing these requests, the server first checks the
authenticity of the requested jobs. Non-legitimate requests
must be checked to determine their authenticity, but checking
consumes CPU utilization, memory and engages the IaaS to a
great extent, and as a result the server will offload its services
to another server. Again, the same thing will occur and the
adversary is successful in engaging the whole cloud system
just by interrupting the usual processing of one server, in
essence flooding the system.
2.2.4 Accountability check problem
The payment method in a cloud System is “No use No
bill”. When a customer launches an instance, the duration of
the instance, the amount of data transfer in the network and the
number of CPU cycles per user are all recorded. Based on this
recorded information, the customer is charged. So, when an
attacker has engaged the cloud with a malicious service or
runs malicious code, which consumes a lot of computational
power and storage from the cloud server, then the legitimate
account holder is charged for this kind of computation. As a
result, a dispute arises and the provider’s business reputation
is hampered
2.3 Possible security approaches
In this section we discuss possible solutions for the three
mostly probable attacks: wrapping attacks, malware-injection
attacks and flooding attacks, as well as an accountability check
for the Cloud system.
2.3.1 Wrapping attack solution
In this regard some additional precautions should be
considered for the reliability of the SOAP message. Two
approaches can be adapted by the registered users in this
message passing:
A Self signed Certificate and RSA key can be
generated for convenience.
Registering a public certificate with the provider.
These certificates will be authenticated by a trusted CA.
We propose that the Security Header must be signed while
passing this message through an unsecured transport layer.
When it is received in the destination, the validation is
checked first. If the Timestamp (discussed in Section III.A) is
not reasonable, then it can be assumed that security has been
breached, actions can be taken accordingly and the SOAP
message can be ignored.
2.3.2 Malware-injection attack solution
The client’s VM is created and stored in the image
repository system of the cloud. These applications are always
considered with high integrity. We propose to consider the
integrity in the hardware level, because it will be very
difficult for an attacker to intrude in the IaaS level. Our
proposal is to utilize a FAT-like (File Allocation Table)
system architecture due to its straightforward technique
which is supported by virtually all existing operating systems.
From this FAT-like table we can find the application that a
customer is running. A Hypervisor can be deployed in the
provider’s end. The Hypervisor is responsible for scheduling
all the instances, but before scheduling it will check the
integrity of the instance from the FAT-like table of the
customer’s VM.
nmap OS
detection
VMI
HYPERVISOR VMI
Windows
Cisco Router
VM 2 VM 1
Secure VM
Figure 4: Guest OS Identification [4]
Now the question is how the FAT-like table will be
utilized to do the integrity checking. The IDT (Interrupt
Descriptor Table) can be used in the primary stage to detect.
Firstly, the IDT location can be found from the CPU
registers; then an analysis of the IDT contents and the hash
values of in-memory code blocks can determine the running
OS in the VM. Finally, using the information of the running
OS with the appropriate algorithms, all the running instances
can be identified and then validated by the Hypervisor. So in
Figure 4 (which is based on [4]), it is observed that the OS of
the VM2 can be easily detected.
2.3.3 Flooding attack solution
For preventing a flooding attack, our proposed approach
is to consider all the servers in the cloud system as a fleet of
servers. Each fleet of servers will be designated for a specific
type of job, like one fleet engaged for file system type
requests, another for memory management and another for
core computation related jobs, etc. In this approach, all the
servers in the fleet will have internal communication among
themselves through message passing, as in Figure 5. So when
a server is overloaded, a new server will be deployed in the
fleet and the name server, which has the complete records of
the current states of the servers, will update the destination
for the requests with the newly included server.
Server 1: File Manager
Name Server
Server 3: Memory Management
Server 2: File Manager Server 1: Core Processor
Server 3: Job Scheduler
Figure 5: Messaging between servers
As mentioned in the previous section, a Hypervisor can
also be utilized for the scheduling among these fleets. The
Hypervisor will do the validity checking and if any
unauthorized code is interrupting the usual computation in
the cloud system, then the system will detect the instance by
introspection. In this way, the flooding attack can be
mitigated to an extent. If the Hypervisor is locally breached,
which would require a misfeasor, then further analysis and
efforts will be required to secure the Hypervisor.
Additionally, a PID can be appended in the messaging,
which will justify the identity of the legitimate customer’s
request. The PID can be checked by the Hypervisor in the
assignment of instances to the fleet of servers. This PID can be
encrypted with the help of various approaches, such as
implementing hash values or by using the RSA.
2.3.4 Accountability check solution
The provider does not know the details of the customer’s
applications and it does not have the privilege to test the
integrity of the application running in the cloud. On the other
hand, customers do not know the infrastructure of the
provider’s cloud. If a customer is charged due to a malware
attack or a failure, then the customer has no option to defend
himself.
There can be unusual phenomenon, such as a dramatic
increase in a current account usage balance all of a sudden or
charges for instances at a specific time when the customer
was away from the cloud. In this case, an investigation
should take place before charging the customer, because an
adversary may be responsible for these unusual activities. In
our approach the following features will be ensured in the
provider’s end before launching any instance of a customer:
Identities
Secure Records
Auditing
Evidence
Firstly, before starting the instance, the identity of the
legitimate customer should be checked by the Hypervisor.
Secondly, all the message passing and data transfer in the
network will be stored securely and uninterrupted in that
specific node. Hence, when the auditing takes place, all the
necessary information can be retrieved. Also, the evidence
must be strong enough to clarify the recorded events, so the
AUDIT will have the following properties: completeness,
accuracy and verifiability. These properties ensure that when
there is a security attack it is reported immediately, no false
alarm will be reported and the evidence can be scrutinized by
a trusted third party who will commit the task of AUDIT
from a neutral point of view.
In some cases, there can be a conflict between privacy and
accountability, since the latter produces a detailed record of
the machines’ actions that can be inspected by a third party.
An accountable cloud can maintain separate logs for each of
its customers and make it visible to only the customer who
owns it. Also, the log available to customers will not have any
confidential information about the infrastructure of the
provider from which the IaaS can be inferred by the
AUDITOR.
3 Conclusions
Cloud computing is revolutionizing how information
technology resources and services are used and managed, but
this revolution comes with new problems. We have depicted
some crucial and well known security attacks and have
proposed some potential solutions in this paper, such as
utilizing the FAT-like table and a Hypervisor.
In the future, we will extend our research by providing
implementations and producing results to justify our concepts
of security for cloud computing. The concepts we have
discussed here will help to build a strong architecture for
security in the field of cloud computation. This kind of
structured security will also be able to improve customer
satisfaction to a great extent and will attract more investors in
this cloud computation concept for industrial as well as future
research farms. Lastly, we propose to build strong theoretical
concepts for security in order to build a more generalized
architecture to prevent different kinds of attacks.
4 References
[1] D. Wentzlaff, C. Gruenwald III, N. Beckmann, K. Modzelewski,
A. Belay, L. Touseff, J. Miller, and A. Agarwal. Fos: A Unified
Operating System for Clouds and Manycore. Computer Science and
Artificial Intelligence Laboratory TR, Nov. 20, 2009.
[2] M. Accetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A.
Tevanian, and M. Young. Mach: A new kernel foundation for
UNIX development. In Proc. of the USENIX Summer Conference,
pp. 93-113, June 1986.
[3] T. Garfinkel, M. Rosenblum, A virtual machine introspection
based architecture for intrusion detection. Proc. 2003 Network and
Distributed Systems Symposium, 2003.
[4] M. Christodorescu, R. Sailer, D. L. Schales, D. Sgandurra, D.
Zamboni. Cloud Security is not (just) Virtualization Security,
CCSW’09, Nov. 13, 2009, Chicago, Illinois, USA.
[5] L. Litty and D. Lie. Manitou: a layer-below approach to fighting
malware. In ASID ’06: Proc. of the 1st workshop on Achitectural
and system support for improving gsoftware dependability, pages
6-11, New York, NY, USA, 2006. ACM.
[6] B.D. Payne, M. Carbone, M. Sharif, and W. Lee. Lares: An
architecture for secure active monitoring using virtualization.
Security and Privacy, IEEE Symposium on, 0:233-247, 2008.
[7]VMware. Virtual Appliance Marketplace.
http://www.vmware.com/appliances/.
[8]Amazon Elastic Compute Cloud (Amazon EC2).
http://aws.amazon.com/ec2.
[9] M. A. Rahaman, A. Schaad, and M. Rits. Towards secure SOAP
message exchange in a SOA. In SWS ’06: Proceedings of the 3rd
ACM workshop on Secure Web Services, pages 77–84, New York,
NY, USA, 2006. ACM Press.
[10] Meiko Jenson, Jorg Schwenk, Nils Gruschka, Luigi Lo
Iacono. On Technical Security Issues in Cloud Computing. IEEE
International Conference on Cloud Computing 2009.
[11] D. Kormann and A. Rubin, “Risks of the passport single
signon protocol,” Computer Networks, vol. 33, no. 1–6, pp. 51–58,
2000.
[12] M. Slemko, “Microsoft passport to trouble,” 2001,
http://alive.znep.com/∼marcs/passport/.
[13] Andreas Haeberlen. A Case for Accountable Cloud. Max
Planck Institute of Software System (MPI-SWS).
[14] S. Gajek, J. Schwenk, M. Steiner, and C. Xuan, “Risks of the
cardspace protocol,” in ISC’09: Proceedings of the 12th
Information Security Conference, LNCS. Springer, 2009.
[15] X. Chen, S. Gajek, and J. Schwenk, “On the Insecurity of
Microsoft’s Identity Metasystem CardSpace,” Horst G¨ortz Institute
for IT-Security, Tech. Rep. 3, 2008.
[16] Nils Gruschka and Luigi Lo Iacono. Vulnerable Cloud: SOAP
Message Security Validation Revisited. NEC Laboratories Europe
Rathausallee 10 D-53757 Sankt Augustin (Germany), 2009 IEEE.
[17] Mladen A. Vouk. Cloud Computing- Issues, Research and
Implementations. Proccedings of the ITI 2008 30th Int. Conf. on
Information Technology Interfaces, June 23-26,2008, Cavtat,
Croatia.
[18] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D.
Joseph, Randy Katz, Andy Konwinski, Gunho Lee, Daviv
Patterson, Ariel Rabkin, Ion Stoica and Matei Zaharia. A View of
Cloud Computing. Communications of the ACM, April 2010.
[19] Nuno Santos, Krishna P. Gummadi, and Rodrigo Rodrigues.
Towards trusted cloud computing. In Proc. HotCloud, June 2009.
[20] Dave Levin, John R. Douceur, Jacob R. Lorch and Thomas
Moscibroda. TrInc: Small trusted hardware for large distributed
system. In Proc. NSDI, April 2007.
[21] Jinpeng Wei, Xiaolan Zhang, Glenn Ammons, vasanth Bala,
Peng Ning. Managing Security of Virtual Machine Images in a
Cloud Environment. CCSW’09, November 13,2009,
Chicago,Illinois, USA.
[22] SOAP, http://www.w3.org/TR/soap/
