SE CLEVER: A Secure Message Oriented Middleware for Cloud ...

SE CLEVER: A Secure Message Oriented Middleware for Cloud Federation Antonio Celesti, Maria Fazio, and Massimo Villari DICIEAMA, University of Messina Contrada di Dio, S. Agata, 98166 Messina, Italy Email: acelesti{mfazio, mvillari}@unime.it Abstract—In this paper, we address several critical security issues that bottle up the wide adoption of the Cloud Computing technology. In the last years the Cloud Security Alliance (CSA) has identified many security issues that should be considered during the design of Cloud systems. We experienced them developing the Security-Enhanced (SE) CLEVER, the secure release of CLEVER, a Message Oriented Middleware for Cloud computing based on the well-known XMPP protocol. SE CLEVER provides a secure inter-module and inter-Cloud communication system useful for managing Federated environments. The secure communication system of SE CLEVER was designed leveraging the XMPP flexibility. The experimental results show how the secure capabilities introduced in SE CLEVER do not affect the overall performances of the middleware. Index Terms—Distributed Systems; Cloud Computing; Federation; XMPP; Security; Trustiness.

I. I NTRODUCTION Cloud Computing is gaining a wide consensus about its utilization in many ICT domains. However, many security concerns are representing a barrier on its adoption in a massive scale. In Cloud, real benefits are out of the door, but issues originated from the bad system management might slow down its growth [1]. The Cloud Security Alliance (CSA) [2] has rather early understood these benefits, but even the potential threats to this growth. In the last years, the alliance has classified threats, risks and vulnerabilities of Cloud systems at any service layer (Infrastructure, Platform, ans Software as a Service). It also has provided Best Practice solutions, applying existing IT Security Standards (i.e., ISO 27000 , SAS 70 Type II audits etc.) and proposing new standards. The CSA guidance [5] seeks to establish a stable, secure baseline for Cloud operations. This effort provides a practical, actionable road map to managers wanting to adopt the Cloud paradigm safely and securely. Considering the CSA guidance, we developed Security-Enhanced (SE) CLEVER, the Security Enhanced release of CLEVER [6], a Message Oriented Middleware for Cloud computing developed at the University of Messina, based on the Extensible Messaging and Presence Protocol (XMPP) that is becoming more and more popular for new emerging Cloud system due to its performance and flexibility. SE CLEVER is a middleware able to setup a secure federation of Clouds belonging to different administration domains. The concept of Federation rely on the possibility to extend computation, networking and storage resources on

978-1-4799-3755-4/13/$31.00 ©2013 IEEE

Federated Clouds (e.g., migrating Virtual Machines from one Cloud provider to another one). However, Federation implies many additional issues [7] and strong requirements in terms of trustiness, data integrity, confidentiality, and non-repudiation. SE CLEVER is able to dynamically setup world-wide intermodule and inter-Cloud communication system via XMPP chat-rooms, where communications can be encrypted and/or signed through X509 certificates, which univocally identify different Cloud entities. The paper is organized as follows. Section II describes related works. The motivations at the basis of this paper are discussed in Section III. In Section IV, we introduce the CLEVER architecture used as the basic environment for the security enforcement aimed at Federated Clouds. Since XMPP is the communication system of CLEVER, an overview of the XMPP and the XEP 0027 security specification is provided in Section V. In Section VI, we discuss how we have designed secure mechanisms in SE CLEVER. Experiments conducted on a real testbed are discussed in Section VII. Section VIII summarizes the work done. II. R ELATED W ORKS Some works are appearing in literature facing security issues in Cloud Computing. Many of them [8][9][10] provide theoretical discussions on different security aspects, but a few try to find concrete assessments and real implemented solutions. In [11], the authors identify security challenges to manage multi-provider Inter-Cloud environments with dedicated communication infrastructures, security mechanisms, processes and policies. The existing security challenges in Collaborative Clouds are highlighted in [12]. The authors analyze different security initiatives, such as the FCAPS model (ISO 10164), that is helpful for describing security management functionalities, and the ISO/IEC 27001, that offers a methodology for managing security services. We agree with the authors in [13], who assert that an Information Technology (IT) auditing mechanisms and framework can play an important role in compliance of Cloud IT security policies. Their survey highlights the possibility to theoretically use recent technologies for enforcing security from different point of views, as well as SAML, OAuth, HMACs, homomorphic linear authenticators (HLAs), identity and access management as a service (IDaaS). A collaboration-based Cloud computing security management framework is presented in [14]. The

000035

alignment of NIST-FISMA standard with the Cloud computing model is reported in a table form. The table reports the responsibilities of Service Providers (SPs), Cloud Customers (CCs) and Cloud Providers (CPs) in managing security assets. The authors in [16] describe a dynamic hierarchical role-based access control model, useful in Cloud service aimed at Mobile Internet. In particular, they introduce an interesting security model with self-adaptive features. Their self-adaptive schema enables their system to automatically meet the environment parameters, hence offering the corresponding protections. Another work that presents possible threats in Cloud is [15]. The authors highlight that when organizations migrate their data or services into the Cloud, they are not aware of their locations. Organizations lose control over their data and are not aware of any security mechanisms put in place by the Cloud provider. In this situation, the main three security concerns are: Loss Of Control, Compliance Implications and Confidentiality and Auditing. Our work focuses the attention on these issues.

III. CSA D IRECTIVES AS THE BASIS OF OUR W ORK

IV. OVERVIEW OF CLEVER CLEVER was conceived as IaaS implementing the VIM layer. In general, a VIM manages the physical resource of a datacenter and it dynamically creates and executes Virtual Machines (VMs) on the hosts, considering their workload and location. In this Section, we describe the main features of the middleware before dealing with the security introduced in SE CLEVER. As depicted in Figure 1, all the CLEVER hosts supply an host level management module, called Host Manager (HM) and just one node includes a cluster level management module, called Cluster Manager (CM). A CM acts as interface between Cloud clients (end-users/applications exploiting the Cloud) and software agents running on HMs. The CM receives commands from clients, gives instructions to the HMs, elaborates information and finally sends results to clients. It also performs tasks for the management of Cloud resources and the monitoring of the working state of the cluster. Software components running in the CM and HMs are called agents. Specifically, we refer to an agent on the CM as Cluster Agent (CA) and an agent on HMs as Host Agent (HA).

According to the Domains and sub-topics investigated by the CSA, we worked on partial security needs for making a concrete solution aimed at IaaS level. The elements we identified in this assessment that are useful in the IaaS context are presented in the CSA guidance [5] and summarized as following: 1) In the Governance and Enterprise Risk Management, there is the need to “divulge policies, procedures and processes comprising the Cloud providers’ Information Security Management System (ISMS)”, knowing who makes what. 2) Whereas in the Information Management and Data Security, it is necessary to “assure that Cloud provider personnel controls are in place to provide a logical segregation of duties.” 3) In the Traditional Security, Business Continuity and Disaster Recovery, “Customers should perform onsite inspections of Cloud provider facilities whenever possible.” 4) Data Center Operation, “Cloud providers must all be able to demonstrate comprehensive compartmentalization of systems, networks, management, provisioning and personnel.” 5) In the Incident Response, Notification and Remediation, “Cloud providers should construct a registry of application owners by application interface (URL, SOA service, etc.)”. 6) Encryption and Key Management, where “segregate the key management from the Cloud provider hosting the data, creating a chain of separation”. All the previous needs can be faced and satisfied using a secure communication middleware as well the one proposed in this paper.

978-1-4799-3755-4/13/$31.00 ©2013 IEEE

Fig. 1. Distributed organization of CLEVER components.

CLEVER supports three types of communication among agents: Internal Remote Method Invoker (IRMI), External Remote Method Invoker (ERMI) and Notification. An IRMI communication refers to the message exchanging protocol among agents within the same manager (both in CMs and HMs). Since agents are separated processes running on the same host, IRMI communications are based on Inter Process Communications (IPCs). ERMI communications allow a CA to exchange messages with HAs. In fact, each CA has knowledge of all the agents in the HMs that depend on the CM itself and it can, also, request for a reply from HAs. Unlike CAs, HAs do not have knowledge of the CAs at the upperlayer of the hierarchy. To allows communications from HAs to CAs, CLEVER uses the Notifications, which are sent from an HA to its CM and does not request for any reply and does not specify the CAs interested in the notification. The sorting of notifications among CAs is demanded to the CM. As the ERMI, also Notifications are based on the XMPP protocols, in order to benefit of flexibility and versatility in communications. Since both ERMI communications and Notifications are based on XMPP, the CLEVER architecture needs

000036

an XMPP Server, which guarantees a high fault tolerance level in communications and allows system status recovery if a crash of a middleware component occurs. The current implementation of CLEVER is based on the employment of an Ejabberd XMPP server [17]. The implementation of our architecture is based on a specific Agent able to locally interact with the SEDNA native XML database [18]. SEDNA allows the possibility of creating incremental hot backup copies of the databases and supports ACID transactions. Although SEDNA cannot be deployed in a distributed fashion, it has been preferred because it natively supports the XML data containers. Thanks to XPath and XQuery capabilities of SEDNA along with the flexibility for defining in run-time the XML DB Schema, SEDNA simplifies the data storage along with the queries to perform on them. In CLEVER, SEDNA is used to log all actions perpetrated among CMs, HMs and the overall Agents. To summarize, as both the XMPP communication system and the distributed database are XML-based, it is rather natural to think at security technologies applied to XML-based messages. V. S ECURE I NSTANT M ESSAGING C OMMUNICATION A valuable solution for the design of a performance and secure Cloud middleware is to conceive its communication system adopting an instant message-oriented approach. To this regard the XMPP (RFC 3920 and RFC 3921), also called Jabber, is becoming more and more popular due to its flexibility to suit different scenarios where a high level of re-activeness is strongly required. Despite it was born for human interaction via chat room it can be used to develop the communication of whatever distributed system well fitting the requirements of Cloud computing. XMPP is an XML-based protocol used for near-real-time, extensible instant messaging and presence information. XMPP remains the core protocol of the Jabber Instant Messaging and Presence technology. The “Jabber” technology leverages open standards to provide a highly scalable architecture that supports the aggregation of presence information across different devices, users and applications. As the client uses HTTP, most firewalls allow users to fetch and post messages without hindrance. Thus, if the TCP port used by XMPP is blocked, a server can listen on the normal HTTP port and the traffic should pass without problems. Custom functionality can be built on top of XMPP, and common extensions are managed by the XMPP Software Foundation. Regarding the security, even though the XMPP specification support the SASL and TLS technologies for the authentication and encryption of the communication channels, it presents some limitations due to the decentralized nature of the protocol that demands the accomplishment of specific security mechanisms to the different implementations. On the other hand, the flexible and extensible nature of the protocol allows to integrate basic security mechanisms, improving the level of the security in the communications. The XEP 0027 [19] specification describes the use of Jabber with the Open

978-1-4799-3755-4/13/$31.00 ©2013 IEEE

Pretty Good Privacy (OpenPGP - RFC 4880 - [20]). OpenPGP is an interoperable specification that provides cryptographic privacy and authentication for data communications. As highlighted by the internet draft, the XEP 0027 does not represent a standard, although it could be in the future, but it describes a possible solution for authentication and data encryption in endto-end XMPP communication. XEP 0027 allows the addition of specific XML tags in the XMPP message, each one defined by a specific namespace: for example “jabber:x:signed” and “jabber:x:encrypted”. Such tags, indicate to the system how to process the information contained within them. As suggested in the specification, it is possible to apply the digital sign of a sender to the message, for example calculating a message digest and signing it with his/her private key. The specification, also allows to sign the presence message in a chat room. In this case it is possible to sign the status of the sender. In the following, it is shown an example of XMPP message sent from the Alice to Bob user.

O n l i n e iQA / AwUBOjU5dnol3d88qZ77EQI2JAC fRngLJ045brNnaCX78ykKNUZaTIoAoP HI2uJxPMGR73EBIvEpcv0LRSy +=45 f 8

The status of alice is signed with her private key, so that bob can verify by means of the Alice’s public key that she is really online. In the same way, it is possible to encrypt the content of the tag body using the public key of the receiver in order to achieve confidentiality. In the following it is shown a message sent from Alice to Bob whose content has been encrypted with the public key of Bob. T h i s m e s s a g e i s e n c r y p t e d . qANQR1DBwU4DX7jmYZnncmUQB / 9 KuKBdd zQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJWp dWpR0uQsuJe7+vh3NWn59 / gTc5MDlX8dS 9 p0ovStmNcyLhxVgmqS8ZKhsblVeuIpQ0 JgavABqibJolc3BKrVtVV1igKiX / N7Pi8 RtY1K18toaMDhdEfhBRzO / XB0+P

The specification does not define the exchange of public keys that is demanded to OpenPGP. Even though the chat messaging is something that purely seem regarding the human interaction, the same approach can by applied to Cloud computing systems in which different distributed software components need to interact each others in both real time and in secure way. VI. S ECURING THE C OMMUNICATION OF SE CLEVER In this Section, we firstly analyze the possible security threads and vulnerabilities that are common to different message oriented Cloud systems and secondly, considering the XMPP, we discuss how several security extensions allow SE CLEVER to meet the CSA requirements.

000037

A. Security Requirements of a Message Oriented Cloud Let us consider a message oriented Cloud system including several distributed software modules or components and whose inter-module communication takes place by means of an instant messaging protocol. The question is: which are the security requirements of the involved communication system? Definitely it should ensure: data confidentiality, data integrity, data authenticity, and data non-repudiation of the sender/receiver. Let us assume that in order to achieve a totally secure communication system each message has to be signed and encrypted by each component. From now on, for

Fig. 2. XMPP messages encryption in CLEVER.

simplicity, we will focus our analysis on the XMPP as instant messaging protocol. Considering the aforementioned security requirements, XMPP as has to be properly extended. In our opinion, considering a Public Key Infrastructure (PKI), the XMMP-based communication of a message oriented Cloud system should support the following functionalities: • Digital identity management. Each component during the in-band registration (i.e., an automatic enrollement of a client on the XMPP server) with the XMPP server requires a digital certificate to a trusted Certification Authority (CA) through the Simple Certificate Enrollment Protocol (SCEP). • Signed message exchange. Each component should be able to sign a message sent to another one. • Encrypted message exchange. Each component should be able to perform a total or partial encryption of a message. • Private chat rooms. The communication system should allow the management of private chat room with restricted access to authorized components. • Encrypted chat rooms. The communication system should allow the management of private and encrypted chat rooms. The key exchange between the communicating components should take place according to a PKI schema. The component that play the role of “moderator” instantiate a new chat room associating a session key. When a new component wants to join the communication, the “moderator” component sends the session key encrypted with the public key of the new component itself. B. XMPP Security Extensions for Message Oriented Clouds As each XMPP message is codified in XML adding an extension means adding a new tag element. In our opinion,

978-1-4799-3755-4/13/$31.00 ©2013 IEEE

in order to make the XMPP enough secure according to the security requirements previously discussed, four basic extensions are required: • Signed. It allows to attach to the message body a digest signed with the private key of the sender component. The signed extension is identified by the XML name space jabber:x:signed () known by all the components. When the message arrives to the receiver component, it detects the signed extension and it queries the LDAP publisher server if an X509 certificate exists for the sender. If it exists, the receiver validates the sign and verifies the message digest according to a shared algorithm. • Encrypted. It allows to attach to the message body a content encrypted with the public key of the receiver component. When a component wants to send an encrypted message, it requests to the LDAP publisher server the X509 certificate of the receiver component. Thus using the public key of the receiver, the sender encrypts the message and it includes the encryption extension identified by the “jabber:x:encrypted” name space (). When the message arrives to destination, the receiver component decrypts it with its private key. This process is schematized in Figure 2. • Session Key. It allows to attach the message a session key. It is used to support an hybrid encryption scheme: the unique share key or the session key is used to encrypt/decrypt the messages by both sender and receiver according to a symmetric encryption scheme (already used in the SSL/TLS protocol), but the session key is exchanged between the two parties according to a public key or asymmetric schema. The advantages of such a hybrid cryptographic scheme is twofold: session key secrecy and faster processing during the encryption of the message. • Timestamp. It allows to attach to the message a signed timestamp, in order to make the message oriented Cloud system normative compliant. These extensions can be accomplished according to the XEP 0027 specification. C. How SE CLEVER meets the CSA Requirements Hereby, we briefly highlight how the the aforementioned security extensions combined with the CLEVER system logging allow SE CLEVER to address the CSA requirements reported in Section III. The CLEVER logging system audits all the events coming from the XMPP messages into SEDNA. Regarding, the possibility to sign exchanged messages (looking at CSA directives Section, in particular item III.1, where it is necessary to divulge all policies, procedures and processes of Cloud providers) it is possible to demonstrate data integrity and assure data non-repudiation (using Timestamps and valid Signatures). The SEDNA XML-based database and the logs of the XMPP communications, related to the Application Owners solve the issue reported in item III.5 The

000038

possibility to encrypt exchanged messages and Session Keys allow to solve the issues reported in III.6. Sign exchanged messages and Timestamps guarantee that customers may perform onsite inspections (see III.3). The analysis may continue, assessing item by item and applying the previous security solutions in each case. VII. E XPERIMENTAL R ESULTS In order to evaluate the impact of XMPP security extensions implemented in SE CLEVER, we have set up a testbed and analyzed the behaviour of the whole system. In our testbed, we integrated in SE CLEVER data encryption and digital sign functionalities adopting the following security tools, libraries, and APIs. i)Enterprice Java Bean Certification Authority (EJBCA). An open source project for the management of a PKI. ii) OpenLDAP. An open source implementation of the LDAP protocol. iii) Bouncy Castle. Open source Java libraries implementing cryptographic algorithms. iv) Java Simple Certificate Enrollment Protocol (JSCEP). An open source Java implementation of the SCEP. v) EJBCA Web Service. An open source Java API for the administration of a CA. vi) Java Naming and Directory Interface (JNDI). An open source Java API for the management of LDAP services. vii) XML Digital Signatures (XMLDsig). An open source Java API that allows to sign and validate XML documents. The

To simulate clients in the testbed, we have instantiate a thread for each client in the AC node. They submit their queries at random time in the range [0; 1] msec, thus to simulate concurrent requests for Cloud services. The system has been evaluated measuring the Elaboration Time Telab in message transmission. It is the time spent to accomplish all the tasks necessary to prepare a message before sending it to the destination (encryption, digest generation,...) and does not include the time for transmission. Thus, it gives a measurement of the complexity in message management and provides the weight of data encryption and signing. We provide results on Telab measurement by increasing the number of clients in the system. Also, we provide results in not encoded, encrypted and signed message transmissions, in the communications from AC to CM and vice versa and from CM to HM and vice versa. From our analysis, we noticed that Telab in transmissions from AC to CM is much more higher that in the other communications (about 95% more). This behavior is due to the simulated scenario for the message generation. In fact, the administration clients work in parallel and their requests are independently sent to the CM, causing an overload on the AC node. On the contrary, CM and HM manage each message sequentially. Since Telab includes only the time for manipulating messages before sending and not the time spent in buffers, it is very lower than the time spent in AC to send messages to the CM. Since the results on AC to CM communications are affected by the specific simulated scenario, we omit them in the following analysis.

Fig. 3. Testbed used for evaluating our SE CLEVER prototype.

experiments were conducted in a testbed with the following hardware: blade server IBM X3630M3 with CPU Intel Xeon E5506 @ 2.13 GHz (8 cores) and 36 GB of RAM. As shown in Figure 3, the testbed consists of three nodes connected over a GB-LAN. A node work as Administration Component (AC), that is responsible of connecting several administrator clients to the CLEVER services. CM and HM are deployed in other two nodes. In order to simulate communication traffic in SE CLEVER, each administrator client submits to the AC a listvms command that queries all the VM registered in HM (step 1). AC formats the request according to The CLEVER specification and sends an XMPP message to CM (step 2). As step 3, CM forwards the request to HM. HM elaborates the request and sends back to CM a reply message (step 4), that CM forwards to AC (step 5). Finally, AC provides VMs information to the clients (step 6).

978-1-4799-3755-4/13/$31.00 ©2013 IEEE

Fig. 4. Elaboration time in not encoded transmission

As shown in Figure 4, in uncoded transmissions, Telab is in the range [0, 7; 1, 1] msec. By increasing the number of clients, it is almost constant, thus proving that the system is not overloaded. In Figure 5, values of Telab are drawn for encrypted messages. In comparison with results on not encoded transmission, Telab increases of an order of magnitude (with few clients, it is about 6 msec). By increasing the number of clients, Telab increases a lot in communications from CM to HM. This effect is due to the hybrid encryption scheme. In fact, to encrypt messages, CM and HM has to exchange the shared key, according to a symmetric encryption scheme. Thus, the communications depends on the queries

000039

several security enforcements on XMPP protocol. This protocol presents many capabilities but the current implementations lacks of strong security features. We delivered and evaluated them over a Virtual Infrastructure Manager develop in UniME, that is CLEVER. The performance analysis of the secure protocol introduced shows the goodness of our approach. ACKNOWLEDGEMENTS The research leading to the results presented in this paper has received funding from the European Union’s Seventh Framework Programme (FP7 2007-2013) Project VISIONCloud under grant agreement number 217019. Fig. 5. Elaboration time in transmission with encription

to the LDAP server. On the contrary, transmissions from CH to CM and from CM to AC are characterized by low Telab , since the nodes already hold the shared keys due their previous communications. Transmissions with signed messages are

Fig. 6. Elaboration time in transmission with sign

characterized by the results in Figure 6. By comparing them with the results in the above Figures, we notice that message signing strongly impacts transmissions (Telab is in the range [50; 80] msec). This is the effect of the asymmetric encryption, which is heavier than the symmetric one implemented in the message encryption service. It explains our design choice to encrypt messages for assuring data confidentiality with the hybrid encryption scheme. The trend of results in Figure 6 is almost independent from the number of clients and this prove that even with 40 concurrent requests, the security mechanisms implemented in the prototype do not overload the whole system. Summarizing, the results drawn from the analysis of our prototype show that security mechanisms proposed in this paper assure confidentiality, authenticity and non-repudiation of data causing inevitable delays due to the encryption activities. However, the low degradation of communication performance does not waste the whole management activity of the Cloud middleware. VIII. C ONCLUSIONS In this paper, we investigated the security issues existing on Clouds and widely described by the Cloud Security Alliance. In order to provide useful solutions in that context, we applied

978-1-4799-3755-4/13/$31.00 ©2013 IEEE

R EFERENCES [1] D. Bruneo, S. Distefano, F. Longo, A. Puliafito, and M. Scarpa, “Workload-based software rejuvenation in cloud systems,” IEEE Transactions on Computers, vol. 99, no. PrePrints, p. 1, 2013. [2] Cloud Security Alliance, http://www.cloudsecurityalliance.org/. [3] Cloud Security Alliance, “Security Guidance for Critical Areas of Focus in Cloud Computing, v3.0,” 2013. https://cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf. [4] A. Celesti, F. Tusa, M. Villari, and A. Puliafito., “Integration of CLEVER Clouds with Third Party Software Systems Through a REST Web Service Interface,” in 17th IEEE Symposium on Computers and Communication (ISCC’12), 1-4 July 2012. [5] A. Celesti, F. Tusa, M. Villari, and A. Puliafito, “Energy Sustainability in Cooperating Clouds,” in Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CLOSER 2013), (Aachen, Germany), 8-10 May 2013. [6] W. Liu, “Research on cloud computing security problem and strategy,” in Consumer Electronics, Communications and Networks (CECNet), 2012 2nd International Conference on, pp. 1216 –1219, april 2012. [7] A. Behl and K. Behl, “Security paradigms for cloud computing,” in Computational Intelligence, Communication Systems and Networks (CICSyN), 2012 Fourth International Conference on, pp. 200–205, July. [8] A. Celesti, N. Peditto, F. Verboso, M. Villari, and A. Puliafito, “DRACO PaaS: a Distributed Resilient Adaptable Cloud Oriented Platform,” in Proceedings of the 18th IEEE Workshop on Dependable Parallel, Distributed and Network-Centric Systems (IEEE DPDNS 2013), (Boston, Massachusetts, USA), May 2013. [9] M. Kretzschmar, M. Golling, and S. Hanigk, “Security management areas in the inter-cloud,” in Cloud Computing (CLOUD), 2011 IEEE International Conference on, pp. 762 –763, july 2011. [10] M. Kretzschmar and S. Hanigk, “Security management interoperability challenges for collaborative clouds,” in Systems and Virtualization Management (SVM), 2010 4th International DMTF Academic Alliance Workshop on, pp. 43 –49, oct. 2010. [11] I. Gul, A. ur Rehman, and M. Islam, “Cloud computing security auditing,” in Next Generation Information Technology (ICNIT), 2011 The 2nd International Conference on, pp. 143–148, June. [12] M. Almorsy, J. Grundy, and A. Ibrahim, “Collaboration-based cloud computing security management framework,” in Cloud Computing (CLOUD), 2011 IEEE International Conference on, pp. 364 –371, july 2011. [13] Z. Lian-chi and X. Chun-di, “Cloud security service providing schemes based on mobile internet framework,” in Computer Science and Electronics Engineering (ICCSEE), 2012 International Conference on, vol. 3, pp. 307 –311, march 2012. [14] A. Behl, “Emerging security challenges in cloud computing: An insight to cloud security challenges and their mitigation,” in Information and Communication Technologies (WICT), 2011 World Congress on, pp. 217 –222, dec. 2011. [15] www.ejabberd.im, “Ejabberd, the Erlang Jabber/XMPP daemon, http://www.ejabberd.im/ jan 2012,” 2012. [16] MODIS group, 2013. Sedna, Native XML Database System: http://modis.ispras.ru/sedna/. [17] 2013. XEP-0027: Current Jabber OpenPGP Usage, http://xmpp.org/extensions/xep-0027.html. [18] 2007. OpenPGP Message Format, http://www.rfc-editor.org/info/rfc4880.

000040