Security Problems of Platform-as-a-Service (PaaS)
Clouds and Practical Solutions to the Problems
Mehmet Tahir Sandıkkaya
Faculty of Computer and InformaticsIstanbul Technical University [email protected]
Ali Emre Harmancı
Faculty of Computer and InformaticsIstanbul Technical University [email protected]
Abstract—Cloud computing is a promising approach for the efficient use of computational resources. It delivers computing as a service rather than a product for a fraction of the cost. However, security concerns prevent many individuals and organizations from using clouds despite its cost effectiveness. Resolving security problems of clouds may alleviate concerns and increase cloud usage; in consequence, it may decrease overall costs spent for the computational devices and infrastructures. This paper particu-larly focuses on the Platform-as-a-Service (PaaS) clouds. Security of PaaS clouds is considered from multiple perspectives including access control, privacy and service continuity while protecting both the service provider and the user. Security problems of PaaS clouds are explored and classified. Countermeasures are proposed and discussed. The achieved solutions are intended to be the rationales for future PaaS designs and implementations.
I. INTRODUCTION
Cloud computing is an emerging concept that provides eco-nomic outsourcing of computational resources [10] and qual-ified maintenance. Various kinds of computational resources are shared via easy-to-use on-demand interfaces through high-capacity networks. It is foreseen [8] (and observed as a growing trend [3]) that people tend to use these online resources since the private investment on computing infras-tructure has become costly [10] and requires specialization. Nevertheless, ubiquitously shared and distributed resources bring together unfamiliar security risks that are far from what information technology professionals are used to.
Eliminating security concerns is likely to ease cloud adop-tion and increase its use. An increase in cloud usage leads to better utilization of the computational resources [7], shortens time to deploy new services, speeds up technology adaptation, eases maintenance, and reduces overall costs as well as overall carbon footprint.
The aim of this paper is to define and classify the technical security risks of PaaS clouds and propose practical solutions to them as an initial effort to build a prototype of a secure PaaS cloud.
Five essential characteristics are enlisted for clouds [13].
• On-demand self-service: The cloud user does not need
any human interaction with the cloud provider.
• Broad network access: Cloud resources are available over
the network and they are easily accessible.
• Resource pooling: Computing resources are shared
a-mong multiple users and assigned relative to the demand.
• Rapid elasticity: The provided resources scale rapidly (They appear to be unlimited.) according to the demand.
• Measured service: Resource usage is automatically mon-itored and optimized.
Cloud computing is classified into three models with respect to the services provided [7], [13]. Infrastructure-as-a-Service (IaaS) accommodates configurable virtual computers for users. PaaS provides a homogeneous computing platform where users can run their applications. Google App Engine [4] and Microsoft Azure [5] are examples of this model. Finally, Software-as-a-Service (SaaS) maintains ready-to-use software. This paper focuses on a flexible PaaS model where users can submit their data to be stored or application to be executed to the cloud through the network1. The resources are shared
among several users while their objects are stored and/or executed with respect to the service agreement. The cloud is composed of several computers (hosts) which can host many user objects. Resources are shared efficiently and elastically by the assignment of objects to hosts and migration of objects among hosts. User objects may interoperate to complete a defined task.
Security risks of PaaS clouds are investigated and respective solutions are presented through Section II. Section III goes into the details of the problems caused by resource pooling and rapid elasticity. Solutions to these problems are presented in the same section. Section IV examines broad network access and measured service characteristics. Privacy-aware authenti-cation is considered in Section V. Section VI is reserved for service continuity and fault-tolerance issues. Summary of the work done and future directions are presented in Section VII.
II. SECURITYRISKS ANDSOLUTIONS
Cloud computing includes many concepts from the past. Therefore, some of its security challenges are familiar. In essence, IaaS clouds resemble virtual machines and SaaS clouds resemble web services from a security perspective. Distinctive security challenges are encountered in the PaaS model.
1Data and/or application are envisioned in a generic structure and this
structure is called user object in the rest of the paper.
2012 31st International Symposium on Reliable Distributed Systems
A. Sources of the problems
Distinctive security challenges of the focused architecture are caused mainly by the spread of the user objects over the hosts of the cloud. Stringently allowing access of objects to the resources and defending the objects against malicious or corrupt providers reasonably reduce possible risks.
Network access and service measurement bring together concerns about secure communications and access control. Well-known practices [2], object scale enforcement of autho-rization and undeniable traceability methods may alleviate the concerns.
Apart from the aforementioned problems, user privacy must be protected in a public, shared cloud. Therefore, proposed solutions must be privacy-aware.
Service continuity is another concern for many enterprises that consider cloud adoption. Accordingly, fault-tolerant reli-able systems are required.
B. Classification of the problems
Security problems introduced by cloud characteristics are classified as follows: Resource pooling and rapid elasticity lead to interoperability problems of heterogeneous resources. Another problem caused by the same reasons is the mutual vulnerability of hosts and objects. Communication confiden-tiality and access control (authentication, authorization and traceability) are required by the broad network access and measured service characteristics of the clouds. Furthermore, privacy and service continuity must be maintained.
III. ISSUES RELATED TO RESOURCE POOLING AND RAPID ELASTICITY
A. Problems
Heterogeneous hardware and software resources are unified for efficient use in cloud environments. Heterogeneity may cause flaws as security settings may differ for different kinds of resources [20]. Information leakage is another problem caused by shared resources as each shared resource is actually a communication channel [15], [18]. Finally, protection of user objects stands as the most serious problem of PaaS clouds.
1) Lack of interoperability: Diverse computational re-sources may lead to security breaches if objects’ access to the resources cannot be handled in a standard way. This may cause a set of resources to halt or a setting that is proven to be secure for a specific resource to be a breach for another.
A simple example is a security breach that is caused by different case sensitivity defaults. A person who is authorized for a file named “file” can gain access to a secret file named “FILE” by mistake.
Interoperability can be maintained by providing common interfaces to objects for resource access. Resource interfaces must be designed carefully to support all possible access scenarios.
2) Vulnerable hosts: Multi-tenancy has been studied since the earliest multi-user operating systems [17]. Today, the concept covers a wider perspective where the user objects are spread over interconnected multi-user hosts. Not only objects but also hosts must be protected from possible attacks in a multi-tenant environment. Such a protection can be achieved by evaluating resource access requests of every single object on the host.
If the security of a host is breached, an attacker can access the host’s resources as well as all of its tenant objects. Therefore, protection against third parties is also a necessity for the host. Taking the essential network security measures is the responsibility of the provider.
3) Vulnerable objects: The security of an object can be breached in one of the following three ways in PaaS clouds. First, service provider may access any user object that reside on its hosts. Second, users may mutually attack each other’s objects that are the tenants of the same host. Finally, a third party may directly attack a user object.
Service provider access to the objects is natural and it is required for the most basic function of a cloud: executing an object. An object is eventually executed unless it is put into the cloud just to be stored. Theoretically, the service provider is capable of accessing and modifying the user objects [16]. Only appropriate cryptographic defense for the user objects during execution is the fully homomorphic encryption schemes [12] –which are computationally expensive and may be insuffi-cient [21]. Therefore, the first kind of attack is inevitable and its solution probably lies in the trust relations of the user and the provider. Still, some parts of the objects may be irrelevant during execution and may be encrypted.
The second kind of attack may occur if tenant objects synchronously share the same resources. These kind of attacks are expected to be prevented by the mechanisms used to evaluate objects’ resource access.
Third kind of attack must be defended by the object itself. Typically, using a secure program logic and secure coding is the responsibility of the programmer.
B. Proposed solutions
Introduced problems can be resolved by two measures. Trusted computing base (TCB) is the solution for the former two problems: lack of interoperability and vulnerable hosts. The third problem is the most challenging one and protecting the sensitive parts of the objects with encryption seems to be the best possible solution.
1) TCB: Trusted computing base is a collection of exe-cutable code and configuration files that is assumed to be secure. TCB is thoroughly analyzed for security flaws and installed as a layer over the operating system and provides a standardized application programming interface (API) for the user objects.
One of the widely-accepted solutions for secure isolation is the principle of minimizing TCB [19], [22]. Minimizing TCB indicates that the complexity of TCB source code is minimized intentionally to omit common coding mistakes or
security flaws. Consequently, TCB appears as a very thin and robust software layer.
TCB is built by classifying the resources, setting resource assignment rules and evaluating resource access requests. Ac-cess to each different kind of resource is abstracted by a unique software object for that kind. Accordingly, when a resource is to be accessed, the corresponding unique software object must be instantiated. During the lifetime of this instance, each call to the methods of this instance is evaluated by TCB to ensure that the callers are permitted through predefined resource assignment rules and only the current subject is accessing the resource synchronously. The resource assignment rules are likely to be produced with respect to the service agreement in between the user and the provider. By-passing TCB without sophisticated knowledge is not generally expected from a standard user.
Interoperability is easily obtained by installing TCB on every host and providing resource assignments via TCB. In consequence, objects always use the same standardized API to access to the resources. Possible attacks from objects to hosts can be prevented as every resource assignment is checked by TCB. Thereby, hosts are protected from malicious user objects. 2) Encrypted objects:The provider is responsible to protect the integrity and privacy of the user object when a user object is on a host. Assuming that the provider is trustworthy, the user does not have any concerns. But, if the provider is malicious or one of its hosts is breached by a malicious party, the object can be read, modified, deleted or rendered inaccessible. Cryp-tographic methods help sensing the modifications or hiding the content. Deletions or denial-of-service (DoS) could not be avoided by encryption, but possible measures are discussed in Section VI.
Well-known cryptographic methods such as symmetric and asymmetric encryption, hashing and signatures can protect contents of an object. Signatures can be used to detect modifications. A fast symmetric encryption algorithm prevents malicious parties to read the contents of an object. The corre-sponding symmetric key can be encrypted with the asymmetric key of the authorized user and it can be attached to the object.
Fig. 1. Object Structure
Unique Object Identifier (plain text, signed by the object owner)
Access Control Policy (plain text, signed by the object owner)
Key/Certificate Storage
(multi-part, each part is encrypted with one of the authorized parties' public keys) Object Content
(multi-part, each part is encrypted with one of the keys stored in the previous field)
An encapsulated key storage field is suitable to keep several keys for different users or roles in different access scenarios. If a set of keys are attached to the object, security of the key storage appears as a new problem. Key storage itself can be encrypted in order to omit malicious viewers. In that case,
objects must include an extra encapsulated field to indicate who can decrypt the key storage. This field is called access control policy, which is discussed in Section IV.
Access control policy helps the host to authorize access to the objects where the keys in the key storage cryptographically enforce this policy. This approach helps to manage access control for each separate object. Therefore, users can decide access control requirements, whom to trust and what to hide for their privacy.
IV. ISSUES RELATED TO BROAD NETWORK ACCESS AND MEASURED SERVICE
A. Requirements
The two requirements to secure a networked system can be derived by basic reasoning. Communications through the network must be confidential and remote entities’ access must be controlled. Access control consists of three concepts: authentication, authorization and traceability. After the con-necting entity is authenticated, predefined access rights of the entities are compared with ongoing requests of the entity. The completed actions or unauthorized requests must be kept in a trustworthy logging system.
1) Communication confidentiality: Confidential communi-cation is the key factor of any networked computer system and PaaS clouds are not an exception in this sense. Objects must communicate in order to interoperate and to be accessed by their owners. The communication channel can be eaves-dropped to extract valuable information as objects reside on remote hosts. Therefore, communication confidentiality must be obtained.
2) Authentication: Authentication is the first element of access control. It requires parties to prove the authenticity of their identities during an interaction. Unprivileged entities may access objects if authentication fails. Current authentication mechanisms are mature enough [2] and PaaS clouds prob-ably do not require novel mechanisms. Still, the standards for the authentication mechanisms must be clear. Another topic regarding authentication is the privacy-awareness of the mechanism which will be discussed in Section V.
3) Authorization: Authorization is the second element of access control. Authorization mechanisms determine who can access to the objects based on predefined policies. Lack of authorization mechanisms may lead to unprivileged access.
Today’s authorization systems generally define access con-trol for static (or slowly evolving) content in predefined domains. Role-based access control and federated access con-trol help administrators manage authorization up to some extent [14]. Still, they may not cover all problems in a PaaS cloud where objects migrate. Moreover, the hosts may be reconfigured in time and it may be difficult to keep up with the policies during these reconfiguration periods.
A host that hosts numerous objects at a given time must know the policies of each object to apply them. The dynamic nature of PaaS clouds does not let the host keep these policies up-to-date locally. Alternatively, the host may try to conduct online queries to fetch the policies of each object. This
approach requires each user to manage a central database for the policies of his objects. This centralized approach may be a burden for the cloud user.
Each object is likely to have its own access control re-quirements as an object may reside on any host at a given time. For example, when an object is moved to a new host, the policies that are effective on the previous host must also be effective on the current host. A practical way is carrying the policies together with the objects. This approach is explained in section IV-B2. The outcome of these policies on the host’s side is the policy enforcement points (PEPs), which are responsible from handling the policies accordingly. PEPs are explained in IV-B3.
4) Traceability: Traceability is the last element of access control. It is achieved through keeping records of the events occurred in a system. In addition to access control needs, mea-sured service characteristic requires fairly kept event records. Event records are important for each cloud stakeholder. Service providers bill the users according to the amount of use; users monitor their applications’ state and audit access to their data; jurisdiction investigates logs in case of conflicts in between parties. Besides, legislation may especially require the logs of some specific sorts of actions, such as access to personal health records [9]. However, many of today’s logging systems assume that the logger is trustworthy. Event records are transmitted and stored by logging systems as simple text records. However, a PaaS cloud must have an integrated undeniable logging mechanism and the logging system must be secure, protected against all interacting parties —including the system administrators.
B. Proposed solutions
Communication confidentiality and authentication require-ments are easily achievable by using Transport Layer Se-curity (TLS) where a public key infrastructure (PKI) exists. Access control policies can be encapsulated together with corresponding objects for ease of distribution and object scale customization. Authorization is applied on the hosts with the help of policy enforcement points (PEPs) with respect to the encapsulated access control policies. Finally, a novel undeniable logging protocol is introduced to build trustworthy logs to trace events occurred in the cloud.
1) TLS: Confidential channels can be formed through Transport Layer Security (TLS) to prevent eavesdropping and for secure authentication [2]. Note that the certificates must belong to the objects but not the hosts as the same host can reside many objects that should communicate through their own channel. Mutual authentication is required to omit man-in-the-middle attacks while accessing the objects.
2) Sticky access control policies: Locally or centrally stored access control policies do not conform to the dynamic nature of the cloud. Encapsulating respective access control policies together with the objects is practical where objects are as-sumed to be atomic user components in a PaaS cloud.
Encapsulating access control policies to the user objects has three main advantages. First, settings are ensured to
be carried together with the objects. Second, an additional connection or component is not needed. Third, reconfiguration is not necessary either within the domain or cross-domain during object migration. Furthermore, encapsulating access control policies carries some of the decision making to the objects instead of trying to keep all access control intelligence centrally. This decision making mechanism, adopted from agent-based systems, fits better to the dynamic nature of the PaaS clouds.
3) PEP: Policy enforcement points (PEPs) manage access to the objects according to the access control policies encapsu-lated within the objects. A PEP is a set of software components responsible to read the encapsulated access control policies of the objects and compare them with the access requests of the parties that are trying to access. Access control policies are evaluated and decisions are made at PEPs of the hosts. The decisions are made after each access request. During the decision making process, PEPs of the hosts must behave according to the undeniable logging protocol explained in Section IV-B4. During the decision, the PEP of a host reads the object’s access control policy and determines whether the connecting party holds the minimum set of identifiers for authentication. If the result of this check is positive, PEP allows the connecting party to access the object as defined in the policy. Otherwise, the connecting party is not authorized.
Fig. 2. Overview of host components and two tenants
Host Operating System TCB (Trusted Code Base) Unique Object Id
Access Control Policy Key/Certificate Storage
Object Content
Unique Object Id Access Control Policy Key/Certificate Storage Object Content … PEP (Policy Enforcement Point) Interfaces for Resource Access Remote Connections
A malicious or corrupt PEP is a major security risk. The less significant attack is collecting unnecessary private data of the accessing users. The PEP may ask more identifiers than stated in the service agreement. Fortunately, evidence of these privacy violating data collection can be recorded by the undeniable logging protocol explained later in Section IV-B4. The more significant attack is DoS. PEP may simply stop responding to remote access requests. Such a misuse can be traced back through the logs. Certainly, fault-tolerant systems are more immune to such attacks. Byzantine quorums are discussed as a solution to unintentional errors or DoS attacks in Section VI.
4) Undeniable logging protocol: Undeniable logging eases to solve the log integrity problem as fake actions cannot be added and valid actions cannot be modified or deleted. A crucial part is making the investigation of the actions
accessible to the related parties. This requires each party be able to check whether the logs are coherent at any given time. Such a feature may be achieved by utilizing an online bulletin board which is a public write-only storage. The records on a bulletin board cannot be altered without notice as they can be copied any time for non-repudiation.
Access requests and corresponding responses are not sent directly to the related parties in the proposed undeniable logging protocol. Instead, the bulletin board acts as a me-diator. Interacting parties follow the published messages on the bulletin board. Therefore, both parties are forced to leave traces before actions. The protocol also prevents misuse like fake requests or responses, as described below. Cryptographic measures are taken to preserve the privacy of the messages published on the bulletin board.
Assuming that a cloud directory service permits to locate objects and a PKI exist, a protocol that satisfies the afore-mentioned requirements is presented in Table I. U, H and B indicate the user, the host and the bulletin board, respectively. U , H and B are used to show the private keys where U0, H0 and B0 indicate public keys. → indicates the direction
of a public channel and ⇒ indicates direction through a private channel. Where the recipient is indicated with an ∗ the messages are published. U , H and O show unique identifiers for the user, for the host and for the object, respectively. U may be a certificate, H may be a unique host name such as a domain name system (DNS) record and O may be a uniform resource identifier (URI). A is the access type, Snis the nthtime stamp,
Nk is the kth nonce, M is the mask, T stands for the access
token to the object and I is the identifier generated for each unique request. ⊕ indicates bitwise XOR. (P )Kindicates that
P is encrypted with K. Similarly, {P }K indicates that P is
signed by K.
TABLE I
UNDENIABLE LOGGING PROTOCOL
1: U → B Req = ((U , H, O, A, S1, N1)U)H0, ((S1, N2)U)B0 2: B → ∗ {I, Req, S2}B 3: U ⇒ H I, N1, N2 4: H → B Res = I, ((T ⊕ M, S3, N1)H)U0, ((M, S3, N2)H)B0 5: B → ∗ {Res, S4}B 6: H ⇒ U M
In the first step, the user generates the message which is called the request. The first part of the request includes identifiers for the user, for the host and for the object that the user requests access to. Additionally, an access type, a time stamp S1and a nonce N1are included. Access type can
be a literal value such as “read”, “write” or “execute”. Time stamp is used to detect the freshness of the messages in the following steps. Nonce is a random value. Everything in the first part of the request is encrypted with the user’s private key and then with the host’s public key. Therefore, the first part is meaningful only for the host. The second part includes the same time stamp and another nonce, N2. This part can only
be decrypted by the bulletin board. The bulletin board checks whether the message is fresh before publishing it.
In the second step, the bulletin board publishes the recently received request as it is. Additionally, the bulletin board adds a unique identifier for this request and a new time stamp S2to
indicate the exact time of publishing. The published messages are signed by the bulletin board to ensure their integrity. At this point, the user can browse the contents of the bulletin board, learn the request identifier and check the correctness of the request as well as its freshness.
In the third step, the user sends the unique identifier I and two nonces N1 and N2 to the PEP of the host over a
secure channel. The host starts evaluating the response by browsing the bulletin board according to the given identifier and checking the existence of the request. Two freshness checks are done before and after decrypting the first part of the request. Comparison of the first nonce sent by the user and the first nonce in the request guarantees that the message is genuine. The validity of the identifiers is checked to authenticate the user. Finally, object’s access control policy is compared with the access type of the request. If this flow is successful, an access token to the object is created.
In the fourth step, the host generates the response. The first part of the response is simply the request identifier. Second part includes the masked token, S3 and N1. An array of
random bits is used to mask the access token. The mask, S3
and N2 are in the third part of the response.
In the fifth step, the request is published on the bulletin board if it is fresh and the nonces match. A new time stamp N4 is added before the published content is signed by the
bulletin board.
In the sixth step, the host sends the mask to the user over a secure channel. After the sixth step, the user can browse the bulletin board and fetch the response. After the decryption, freshness check and comparison of nonces, the masked access token is XORed with the sent mask and the unmasked access token is derived. In case the host posts an invalid token in the response or simply does not send the mask to the user, the bulletin board can collaborate to derive the access token or at least witness its invalidity.
V. PRIVACY-AWARE AUTHENTICATION
Generally, more user-specific information than necessary is requested during conventional authentication. For example, access to a printer may require revealing the identity where only being an employee of the company is enough. This might not be a problem in the perimetrical computer systems as the user is likely to be authenticated in advance. On the other hand, users should not leave more trace than necessary to protect their privacy where the resources are spread over several hosts. Proxy certificates [1] can help to reduce the risk of revealing excess attributes. A proxy certificate is an electronic certificate that includes only the required attributes of the corresponding identity.
Two requirements must be met during privacy-aware au-thentication with proxy certificates. First, hosts and objects should not request more attributes than the required amount. This depends on how access control policies are defined.
Policies for the hosts and objects are defined by the service providers and the users, respectively. If more attributes than required is requested, the only practical solution is negotiating the service terms. Second requirement is easily configurable trustworthy credentials that reveal as much data as the identity owners permit. This can be achieved with the help of a trusted third party.
Proxy certificate authorities (PCAs) can handle dynamic generation of attribute-based credentials based on genuine certificates and witness that a user holds the required attributes. PCAs can link genuine certificates to proxy certificates in case of a conflict. They not only keep track of the issued proxy certificates and the corresponding genuine certificates, but also sign the proxy certificates for non-repudiation.
PCAs can be independent services provided in the cloud or they can be the original issuers of the genuine certificates. The number of proxy certificates can be reduced by reusing them where linkability is acceptable. Therefore, the overhead of generating on-the-fly proxy certificates is reduced. Scalability can be achieved by utilizing multiple hierarchical PCAs. VI. SERVICE CONTINUITY AND FAULT-TOLERANCE ISSUES
There may be several reasons for a service to stop re-sponding in a networked environment. The reason may be a malfunction or an attack. A service may stop interacting for some period of time. Access to the objects may be limited or disabled. More seriously, an object’s content may be modified or the object may be wiped out completely.
Byzantine quorum [11] approach is adopted to obtain fault-tolerance and service continuity under these circum-stances. In the Byzantine quorum approach, any subset of all hosts that resides the copies of the same object forms a quorum. Where the number of reliable hosts are enough, a consistent copy of the object can be determined. Therefore, modifications on an object can be detected or inaccessible objects can be recovered in the Byzantine quorum systems. This approach is a generic protection against service unavail-ability in cloud environments. A survey of such systems and an extensive example are shown on [6].
VII. CONCLUSION
Solutions to secure a PaaS cloud are proposed in this paper by considering the mentioned security weaknesses of PaaS clouds. If the assumptions presented in this paper are hold, it can be reasonably said that a design that utilizes proposed solutions would be secure against the attacks mentioned above. To the best of our knowledge, such a multi-perspective solution set that permits a secure PaaS design is not yet reported.
A secure PaaS cloud can only be achieved through thor-oughly inspecting the conceptual security solutions, archi-tectural and software design, implementation and service provisioning. A complete cloud implementation that takes the presented security concerns into account and develops the proposed solutions is not encountered in the literature. Currently, we are planning to implement a prototype cloud to exemplify and integrate the presented conceptual solutions.
Further studies will certainly lead to better understanding of secure PaaS clouds and proposed solutions will be inspira-tional to build more secure, usable and scalable ones.
REFERENCES
[1] Rfc 3820: Internet x.509 public key infrastructure (pki) proxy certificate profile, Dec 2004. http://tools.ietf.org/html/rfc3820.
[2] Rfc 5246: The transport layer security (tls) protocol version 1.2, Dec 2010. http://tools.ietf.org/html/rfc5246.
[3] Amazon s3 reports staggering growth in 2011, Jan 2012. http://www. readwriteweb.com/cloud/2012/01/amazon-s3-says-it-tripled-in-o.php. [4] Google app engine, July 2012. https://developers.google.com/
appengine/.
[5] Windows azure platform, July 2012. http://www.windowsazure.com/ en-us/.
[6] A. Bessani, M. Correia, B. Quaresma, F. Andr´e, and P. Sousa. Depsky: dependable and secure storage in a cloud-of-clouds. In Proceedings of the sixth conference on Computer systems, EuroSys ’11, pages 31–46, New York, NY, USA, 2011. ACM.
[7] G. Brunette. Security guidance for critical areas of focus in cloud computing v2.1. Technical report, Cloud Security Alliance, Dec 2009. http://www.cloudsecurityalliance.org/csaguide.pdf.
[8] D. Catteddu and G. Hogben. Cloud computing: Benefits, risks and recommendations for information security. Technical report, ENISA, Nov 2009. http://www.enisa.europa.eu/act/rm/files/deliverables/ cloud-computing-risk-assessment.
[9] P.P. Gunn, A.M. Fremont, M. Bottrell, L.R. Shugarman, J. Galegher, and T. Bikson. The health insurance portability and accountability act privacy rule: a practical guide for researchers. Medical Care, 42(4):321–327, 2004.
[10] L.M. Kaufman. Data security in the world of cloud computing. IEEE Security & Privacy, 7(4):61–64, 2009.
[11] L. Lamport, R. Shostak, and M. Pease. The byzantine generals problem. ACM Trans. Program. Lang. Syst., 4(3):382–401, July 1982.
[12] A. L´opez-Alt, E. Tromer, and V. Vaikuntanathan. On-the-fly multiparty computation on the cloud via multikey fully homomorphic encryption. In Proceedings of the 44th symposium on Theory of Computing, STOC ’12, pages 1219–1234, New York, NY, USA, 2012. ACM.
[13] P. Mell and T. Grance. The nist definition of cloud computing v15. Technical report, National Institute of Standards and Technology, June 2009. http://csrc.nist.gov/groups/SNS/cloud-computing/.
[14] E.E. Mon and T.T. Naing. The privacy-aware access control system using attribute-and role-based access control in private cloud. In Broadband Network and Multimedia Technology (IC-BNMT), 2011 4th IEEE International Conference on, pages 447–451, oct. 2011. [15] T. Ristenpart, E. Tromer, H. Shacham, and S. Savage. Hey, you, get
off of my cloud: exploring information leakage in third-party compute clouds. In E. Al-Shaer, S. Jha, and A.D. Keromytis, editors, ACM Conference on Computer and Communications Security, pages 199–212. ACM, 2009.
[16] F. Rocha and M. Correia. Lucy in the sky without diamonds: Stealing confidential data in the cloud. In Proceedings of the 2011 IEEE/IFIP 41st International Conference on Dependable Systems and Networks Workshops, DSNW ’11, pages 129–134, Washington, DC, USA, 2011. IEEE Computer Society.
[17] J.H. Saltzer. Protection and the control of information sharing in multics. Commun. ACM, 17(7):388–402, 1974.
[18] J.H. Saltzer and M.D. Schroeder. The protection of information in com-puter systems. Proceedings of the IEEE, 63(9):1278–308, sep. 1975. [19] U. Steinberg and B. Kauer. Nova: a microhypervisor-based secure
virtu-alization architecture. In Proceedings of the 5th European conference on Computer systems, EuroSys ’10, pages 209–222, New York, NY, USA, 2010. ACM.
[20] H. Takabi, J.B.D. Joshi, and G. Ahn. Security and privacy challenges in cloud computing environments. Security Privacy, IEEE, 8(6):24–31, nov.-dec. 2010.
[21] M. van Dijk and A. Juels. On the impossibility of cryptography alone for privacy-preserving cloud computing. IACR Cryptology ePrint Archive, 2010:305, 2010.
[22] G. van ’t Noordende, B.J. Overeinder, R.J. Timmer, F.M.T. Brazier, and A.S. Tanenbaum. Constructing secure mobile agent systems using the agent operating system. IJIIDS, 3(4):363–381, 2009.