Pierre Meye
email: pierre.meye@orange.com

Philippe Raipin
email: philippe.raipin@orange.com

Frédéric Tronel
email: frederic.tronel@supelec.fr

Emmanuelle Anceaume
email: anceaume@irisa.fr

A secure two-phase data deduplication scheme

Keywords: Cloud storage, Intra-user deduplication, Inter-user deduplication, Confidentiality, Deduplication proxy

Data grows at the impressive rate of 50% per year, and 75% of the digital world is a copy 1 ! Although keeping multiple copies of data is necessary to guarantee their availability and long term durability, in many situations the amount of data redundancy is immoderate. By keeping a single copy of repeated data, data deduplication is considered as one of the most promising solutions to reduce the storage costs, and improve users experience by saving network bandwidth and reducing backup time. However, this solution must now solve many security issues to be completely satisfying. In this paper we target the attacks from malicious clients that are based on the manipulation of data identifiers and those based on backup time and network traffic observation. We present a deduplication scheme mixing an intraand an inter-user deduplication in order to build a storage system that is secure against the aforementioned type of attacks by controlling the correspondence between files and their identifiers, and making the inter-user deduplication unnoticeable to clients using deduplication proxies. Our method provides global storage space savings, per-client bandwidth network savings between clients and deduplication proxies, and global network bandwidth savings between deduplication proxies and the storage server. The evaluation of our solution compared to a classic system shows that the overhead introduced by our scheme is mostly due to data encryption which is necessary to ensure confidentiality.

I. INTRODUCTION

The amount of data to be stored by cloud storage systems increases extremely fast. It is thus of utmost importance for Cloud Storage Providers (CSPs) to dramatically reduce the cost to store all the created data. A promising approach to achieve this objective is through data deduplication [START_REF] Dutch | Understanding data deduplication ratios[END_REF], [START_REF] Russel | Data deduplication will be even bigger in 2010[END_REF]. Put simply, data deduplication keeps a single copy of repeated data. When a client wishes to store some piece of data, and if a copy of this data has already been saved in the storage system, then solely a reference to this existing copy is stored at the storage server. No duplicate is created. There are diverse forms of data deduplication. It can be done by a client solely on the data he/she has previously stored in the system, a technique commonly called intra-user deduplication, or it can be achieved by taking into account the data previously stored by all the clients. In this case it is designated as inter-user deduplication. Data deduplication also improves users experience by saving network bandwidth and reducing backup time when the clients perform the deduplication before uploading data to the storage server. This form of deduplication is termed as client-side deduplication, and when it is handled by the storage server it is called server-side deduplication. Due to its straightforward economical advantages, data deduplication is gaining popularity in both commercial and research storage systems [START_REF] Dutch | Understanding data deduplication ratios[END_REF], [START_REF] Meyer | A study of practical deduplication[END_REF], [START_REF] Russel | Data deduplication will be even bigger in 2010[END_REF].

However, several works have recently revealed important security issues leading to information leakage to malicious clients [START_REF] Halevi | Proofs of ownership in remote storage systems[END_REF], [START_REF] Harnik | Side channels in cloud services: Deduplication in cloud storage[END_REF], [START_REF] Mulazzani | Dark clouds on the horizon: using cloud storage as attack vector and online slack space[END_REF], [START_REF] Storer | Secure data deduplication[END_REF]. These security concerns arise especially in systems performing an inter-user and client-side deduplication which is unfortunately the kind of deduplication that provides the best savings in terms of network bandwidth and storage space. Hereafter, we summarize in three categories the most common types of attacks described in the literature.

Manipulation of data identifiers:

A common technique to deduplicate data is by hashing the content of the data and using this (unique) hashed value as the identifier of the data. Then the client sends this identifier to the storage server to determine whether such an identifier already exists in the system. An attacker can easily exploit this technique to perform various types of attacks. The CDN attack [START_REF] Harnik | Side channels in cloud services: Deduplication in cloud storage[END_REF] turns a cloud storage system into a Content Delivery Network (CDN). Suppose that Bob wants to share a file F with Alice. Bob uploads F to a cloud storage system and sends F identifier to Alice. When Alice receives it, she tries to upload F to the same cloud storage system by sending F identifier. The storage system will detect that this identifier already exists. Consequently, solely a reference meaning that Alice also owns file F will be stored in the system which is actually wrong. At this point, when Alice wants to download F , she just needs to request it from the cloud storage system. There is also an attack called targeted collision [START_REF] Storer | Secure data deduplication[END_REF] in which, a malicious client uploads a piece of data (e.g, a file) that does not correspond to the claimed identifier. Suppose that Bob wants to cheat Alice. If no control is made by the cloud storage system, Bob can upload a file F 1 with the identifier of a file F 2 . Then, if Alice wishes to upload F 2 with its real identifier, the system will detect the existence of F 2 identifier in the system and will not store F 2 . Rather, the system will store a reference meaning that Alice also owns file F 1 which is the file corresponding to the identifier of F 2 in the system. Later, when Alice will request the file corresponding to the identifier of F 2 , the system will send F 1 to Alice.

Network traffic observation:

Monitoring the network traffic on the client side gives an attacker the capability to determine whether an inter-user deduplication has been applied on a given piece of data. Such an attacker can exploit this knowledge to identify data items stored in a cloud storage system by other users or even learn the content of these data items [START_REF] Bellare | Dupless: Server-aided encryption for deduplicated storage[END_REF], [START_REF] Harnik | Side channels in cloud services: Deduplication in cloud storage[END_REF]. For instance, to determine whether a file F is stored in a system, the attacker just tries to upload F and observes the network traffic from his/her device toward the storage server. If F is uploaded, it means that F does not exist in the storage system. The attacker is not even obliged to upload the complete file. He/she can prematurely abort the upload, so that the attack can be repeated later. On the other hand, if the file is not uploaded, the attacker can conclude that the file already exists in the system. This fact makes the storage system vulnerable to brute force attacks on file contents [START_REF] Bellare | Dupless: Server-aided encryption for deduplicated storage[END_REF], [START_REF] Harnik | Side channels in cloud services: Deduplication in cloud storage[END_REF]. For instance, to determine which copies of a movie exist on a specific cloud storage system, an attacker can upload each format or version of such a movie, and show that those that are not uploaded already exist in the storage system.

Backup time observation: Detecting an inter-user deduplication by observing the backup duration [START_REF] Suzaki | Memory deduplication as a threat to the guest os[END_REF] gives an attacker the ability to perform the same attacks as the ones done with network traffic observations. However, observing the duration of a backup operation is less accurate than a network traffic monitoring as it depends on the size of the file and the state of the network. For small files, observation may not be accurate, while for larger ones, it gains in accuracy.

There have been lots of efforts devoted to deal with these issues and provide a secure and efficient data deduplication [START_REF] Bellare | Dupless: Server-aided encryption for deduplicated storage[END_REF], [START_REF] Bellare | Message-locked encryption and secure deduplication[END_REF], [START_REF] Pietro | Boosting efficiency and security in proof of ownership for deduplication[END_REF], [START_REF] Halevi | Proofs of ownership in remote storage systems[END_REF], [START_REF] Harnik | Side channels in cloud services: Deduplication in cloud storage[END_REF], [START_REF] Heen | Improving the resistance to side-channel attacks on cloud storage services[END_REF], [START_REF] Liu | Policy-based de-duplication in secure cloud storage[END_REF], [START_REF] Mulazzani | Dark clouds on the horizon: using cloud storage as attack vector and online slack space[END_REF], [START_REF] Ng | Private data deduplication protocols in cloud storage[END_REF], [START_REF] Storer | Secure data deduplication[END_REF], [START_REF] Xu | Weak leakage-resilient client-side deduplication of encrypted data in cloud storage[END_REF], [START_REF] Zheng | Secure and efficient proof of storage with deduplication[END_REF]. However, we are not aware of any single solution that is capable of addressing, at the same time, the three types of attacks that malicious users can attempt on the deduplication system. This is the objective of this paper.

A. Our contributions

Our work takes place in the context of an Internet Service Provider (ISP) providing also the storage system 2 . That is to say, the ISP which is also the CSP has strong economical reasons to (i) save storage space and network bandwidth as it masters all the network and storage infrastructure, and (ii) provide a secure storage service to its consumers. We propose a deduplication solution to build a storage system that positively answers the following three questions:

1) Can we guarantee that the identifier used to trigger deduplication corresponds to the claimed data item? 2) Can we determine that a client actually owns the data item corresponding to the identifier issued to the storage system? 3) Can we make the inter-user deduplication transparent (i.e. unnoticeable even in the case of backup time or network traffic observation) to clients and still provide network bandwidth savings?

Our deduplication scheme is simple and robust against the aforementioned attacks while remaining efficient in terms of storage space and bandwidth savings for both clients and the CSP. We consider data deduplication at a file level granularity but our solution can be extended to the block level. Specifically our approach is a two-phase deduplication that leverages and combines both intra-and inter-user deduplication techniques by introducing deduplication proxies (DPs) between the clients and the storage server (SS). Communications 2 For instance the french ISP Orange provides various cloud storage system. from clients go through these DPs to reach the SS which allows to split the deduplication process as illustrated in Figure 1.

The intra-user deduplication: This phase is performed by clients. It aims at saving clients network bandwidth by guaranteeing that each client uploads no more than once each of his/her file to a DP (i.e. per-client savings). In addition, we strengthen data confidentiality by letting clients encrypt their files before uploading them. Regarding security, we exploit the fact that the scope of the intra-user deduplication is limited to the files previously stored by the client trying to store a file. It allows the storage system to be protected against both CDN attacks and network traffic observations ones. Briefly, in the former case, each client uploads each of his/her files to his/her associated DP exactly once even if the same files already exist in the storage system (due to a prior upload by an other client). This accordingly prevents any client from determining whether a file already exists in the storage system through network traffic observations. The inter-user deduplication: This phase is performed by the DPs. Alongside the economical benefits offered by this scheme thanks to global storage space savings (i.e. only a single copy of a file is stored independently of the number of owners of this file), it provides also global network bandwidth savings between DPs and the SS as a single copy of any file has to be sent to the SS. Note that to make indistinguishable the upload of a file to the SS from the sending of a referencewhen the referred file already exists in the storage systemthe concerned DP may introduce an extra delay before sending the notification to the client. The goal of adding this delay is to make similar the duration of storing a reference and storing the entire file. This aims to protect the system against attacks based on backup time observation.

Consistency of files and their identifiers:

To protect the storage system against targeted-collision attacks, consistency between a file and its identifier is checked by the DPs before sending the file to the SS and before applying the inter-user deduplication (i.e. sending only a reference to the SS).

The remainder of the paper is organized as follows. Section II details the system model and the assumptions we made about the system. Section III focuses on the two fundamental operations that allow to store and retrieve files in the system. Section IV presents a performance evaluation of our solution, and Section V a discussion on security issues. Section VI exposes the related work. Conclusion and future work are presented in Section VII.

II. SYSTEM MODEL

Our system consists of the following three types of components:

Client (C): Any authenticated user accessing the storage system.

Storage Server (SS):

A server in charge of storing and serving clients files. The storage server also maintains an index of all the files stored in the storage system and their owners.

Deduplication Proxy (DP):

A server associated with a given number of clients. Clients communicate with the SS via their associated deduplication proxy. A deduplication proxy is involved in both the intra-user and the inter-user deduplication (See Section III).

The orchestration of the proposed architecture is illustrated in Figure 1. The SS and the DPs are operated by the CSP.

A. Threat model

We suppose that the CSP is trusted to behave correctly to ensure the clients files availability and long term durability, however it follows the honest but curious adversary model. Namely, it may take actions to disclose file contents. Regarding clients, we assume that some of them are malicious. They may try to perform the types of attacks mentioned in Section I. We suppose that there is no coalition between the entities provided by the CSP (i.e. the SS and the DPs) and the clients. Finally, we consider that communication channels are reliable through the use of cryptographic protocols such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

B. Data encryption

We make the hypothesis that entities have access to a hash function, denoted by hash in the following, that is pre-image resistant (i.e. given a hash value, it should be hard to find any file that hashes to that hash value), second pre-image resistant (i.e. given a file F 1 , it should be hard to find a different file F 2 such that F 1 and F 2 hash to the same value), and collision resistant (i.e. it should be hard to find two different files F 1 and F 2 that hash to the same value).

While the adoption of cloud storage services to outsource data is steadily growing, its benefits come with some inherent risks implied by the fact that full control on data is given to the CSPs [START_REF] Kamara | Cryptographic cloud storage[END_REF], [START_REF] Ren | Security challenges for the public cloud[END_REF], [START_REF] Rocha | The final frontier: Confidentiality and privacy in the cloud[END_REF]. Clients (e.g., individuals, scientists, enterprises, governmental agencies, etc) may want to restrict the control or access of the CSP to their sensitive data in order to preserve some confidentiality. We assume that clients have the ability to encrypt and decrypt data with both asymmetric (encrypt asym and decrypt asym ) and symmetric (encrypt sym and decrypt sym ) cryptographic functions and manage their own private and public personal keys for the asymmetric encryption scheme. In our approach, clients encrypt their files using a convergent encryption scheme [START_REF] Bellare | Dupless: Server-aided encryption for deduplicated storage[END_REF], [START_REF] Bellare | Message-locked encryption and secure deduplication[END_REF], [START_REF] Douceur | Reclaiming space from duplicate files in a serverless distributed file system[END_REF], [START_REF] Liu | Policy-based de-duplication in secure cloud storage[END_REF], [START_REF] Xu | Weak leakage-resilient client-side deduplication of encrypted data in cloud storage[END_REF]. Specifically, to encrypt a file F with this scheme, the hashed value of F is used as an encryption key to encrypt F using a cryptographic symmetric function. Thus, the same file encrypted by different clients will result in equal ciphertexts. This allows the CSP to detect duplicates and to apply an inter-user deduplication on encrypted files without any knowledge of their plaintext contents.

III. SYSTEM DESIGN

This section describes the put and get operations, that allow clients to respectively store and retrieve their files.

A. The put operation

When a client wishes to store a file in the storage system, he/she triggers a put operation. This operation, illustrated in Figure 2, involves two types of interactions, the first one between the client and a DP, and the second one between this DP and the SS. In the following, the client invoking the put operation for a file F is denoted by its identifier C id . Before interacting with the DP, C id builds the different parameters of the functions of the put operations. First, it creates the encryption key by hashing F content as follows,

F hash ← hash(F ).
Then, C id encrypts the file F by applying a symmetric encryption function on F using F hash as a key leading to the ciphertext {F } F hash . We have

{F } F hash ← encrypt sym (F hash , F ).
Finally, C id creates F identifier F id as

F id ← hash({F } F hash ).
The previous steps allow different clients to create the same identifier for a given file, and enable to check the consistency between an encrypted file and its identifier by just comparing the hashed value of the encrypted file and the received identifier. Once client C id has created the parameters of the put operation, he/she sends a checkForDedup request to the DP to inform it that he/she wants to store F . This request is directly forwarded to the SS that checks whether a data deduplication and which kind of deduplication must be applied (i.e. either an intra-user deduplication or an inter-user one). This is achieved by looking for F id and its potential owners in the file ownership index maintained by the SS. According to the outcome of this search, the SS sends one of the following three responses to the DP. 1) (C id , F id , Intra-user deduplication). C id has already stored the file corresponding to F id . Thus, by construction of our deduplication process, the file upload is not necessary; the DP directly forwards the response to C id . 2) (C id , F id , File upload). In this case, the file corresponding to F id does not exist in the storage system, which requires that C id must upload it; the DP directly forwards the response to the client. 3) (C id , F id , Inter-user deduplication).

The file corresponding to F id has already been stored in the storage system by a client different from C id . Thus, an inter-user deduplication must be applied by the DP. However, in order to hide this inter-user deduplication to the client, instead of directly forwarding this response to C id , the DP sends him/her a file upload response, and memorizes that this upload is requested due to an inter-user deduplication. uploads to the DP his/her client identifier, the encrypted file {F } F hash , the file identifier F id , and the decryption key encrypted with its public key as follows,

{F hash } K C id ← encrypt asym (K C id , F hash ),
which guarantees that {F hash } K C id can only be decrypted using C id private key. Client C id waits for the response of the DP.

When the DP receives the uploadFile message from C id , it applies a consistency check in order to prevent target-collision attacks. A targeted-collision is detected when the hash value of the encrypted file is not equal to the identifier received. In that case, the operation is aborted, and a notification is sent via an uploadFileResponse to client C id . This ends the put operation. If the consistency check is successful and the file upload has been requested because of an inter-user deduplication, then only a reference (i.e. the client identifier C id , the file identifier F id , and the encrypted decryption key {F hash } K C id ) is uploaded to the SS to be stored. Recall that the DP has to ensure that this inter-user deduplication is unnoticeable to the client. Thus, before sending the notification (i.e. an uploadFileResponse message) to C id , the DP delays it to make the duration of the whole put operation similar to a transmission of the file to the SS. The added delay is thus a function of the size of the file and the state of the network. On the other hand, if the file upload has been requested because that file does not exist in the storage system, then the uploadFile message is simply forwarded to the SS in the case where the consistency check has been successfully passed.

B. The get operation

The get operation is invoked by clients to retrieve their own files from the storage system. Figure 3 illustrates the process of a get operation. Our deduplication scheme pushes all the complexity to the put operation. In get operations, the DPs only forward the requests and responses they respectively receives from the clients and the SS. Specifically, upon receipt of a get request from a client C id about a file of identifier F id , the DP simply forwards it to the SS which looks for F id in its file ownerships index. If F id is not found among the identifiers of files belonging to C id , the SS sends a getResponse message to the DP with an error notification to terminate the get request. Otherwise, the SS sends a getResponse containing the ciphertext {F } F hash corresponding to the identifier F id and the encrypted decryption key {F hash } K C id corresponding to the client C id . In both cases, the DP only forwards the getResponse to the client C id who will apply an asymmetric decryption function on the encrypted key using its private key K -1

C id to recover key F hash , where

F hash ← decrypt asym (K -1 C id , {F hash } K C id ).
Finally, the plaintext of F is obtained with

F ← decrypt sym (F hash , {F } F hash ).

IV. IMPLEMENTATION

We have implemented two storage system prototypes to compare the performance overhead of our proposition with respect to a classic storage system with no data encryption. Specifically, we have developed a classic storage system with a client and a storage server software modules, and one implementing our proposition with a client, a deduplication proxy and a storage server software modules. All these software modules are implemented in python 2.7.6 and access the pycrypto library for the cryptographic operations. We use the SHA256 algorithm as the hash function, RSA1024 for asymmetric encryption operations, and AES for the symmetric encryption operations with keys that are 256 bits long. The storage servers use the MongoDB3 database to store the meta-data of the stored files as well as files owners. The software modules are executed on three different virtual machines (VMs) running on Ubuntu 12.04.4 LTS with 1GB of memory and an AMD Opteron(TM) octa-core Processor 6220@3GHz. The network topology is as follows: the VM executing the DP software is located on the network path between the VM running the different clients modules and the one executing the different SSs modules. Figure 4 and Figure 5 compare the different costs induced by the put and get operations in a classic storage system and in the one we propose. Each result regarding both put and get operations is the average of 1000 experiments run with files whose sizes range from 2MB to 64MB. The first straightforward observation that can be drawn from both figures is that the cost of both operations fully depends on the size of the stored files. In put operations, the overhead in our scheme is due to the encryption key creation, the encryption key encryption 4 , the file encryption, the consistency check of a file and its identifier performed by the DP module, and the communication overhead introduced by handling the file by the DP. On the other hand, for get operations, the overhead in our proposition comes from the encryption key decryption 4 , the file decryption, and the communication overhead of the DP. However, this overhead is small, as it entails around 0.5s on average per file of 64MB length. Actually, most of the overhead incurred in our solution is due to file encryption during a put operation and file decryption during a get operation. Indeed, up to 12-13s are needed on average for encrypting/decrypting a file that is 64MB length.

Figure 6 gives a performance comparison between an interuser deduplication applied in a classic scheme and the intraand inter-user deduplication applied in our proposition. The inter-user deduplication experiments consist in storing files at a given client and having one thousand clients accessing them through the put operation. The intra-user deduplication experiment consists in storing thousand times the same files at a single client. The results plotted in Figure 6 represent the average duration values of the these operations. We observe that the intra-user deduplication in our scheme consumes more communication resources than an inter-user deduplication in a classic scheme due to the use of a DP (around 18ms of overhead for a file of 64MB length). However most of the overhead comes from the encryption key creation, the encryption key encryption 4 and the file encryption which depends on the file size. We also observe that operations involving the interuser deduplication in our scheme have higher durations than the ones involving an intra-user deduplication. This is due to (i) the overhead of communications when applying the interuser deduplication because the file has to be uploaded to the DP and then a reference is uploaded to the the SS and (ii) the added delay by the DP to make unnoticeable the inter-user deduplication to client. Actually in our scheme, a put operation involving an inter-user deduplication has a similar duration than a file upload from the client to the SS.

V. DISCUSSION

In this section, we discuss the impact of the proposed solution regarding the data security and the network bandwidth savings.

As previously described our solution aims at protecting the storage system against the manipulation of data identifiers, network traffic observation and backup time observation (See Section I). This is achieved by placing deduplication proxies between clients and the storage server, and by running a two-phase deduplication scheme. Now, by taking advantage of the intra-user deduplication performed between clients and their DP, from a client point of view, the visibility of what is stored in the storage system is limited to his/her own account. If a client has not previously stored its file then he/she must upload it to his/her associated DP, which protects the system against the CDN attacks and the attacks based on network traffic monitoring. In order to prevent the targeted-collision attacks, the DP performs a consistency control on both the file and the identifier received from a client before sending this file to the storage server or before applying the inter-user deduplication. To make the inter-user deduplication unnoticeable to clients in order to face the attacks based on backup time observation, the DP adds some delay before terminating the put operation (i.e. before sending the uploadFileResponse). Recall that a delay may be added only when an inter-user deduplication is applied. In addition, by using a convergent encryption scheme, the CSP can perform an inter-user deduplication on client data without any access to their plaintext and achieve global storage space savings.

A. Impact of the localization of the deduplication proxy

The benefits of our proposition regarding the network bandwidth savings highly depends on the localization of the DPs in the storage infrastructure which may also impact the level of security of the solution. In the following, we briefly discuss the pros and cons of the DPs localization.

Deduplication proxies collocated with clients devices: If deduplication proxies are hosted by clients, then both intra-and inter-user deduplication need to be applied at the client sides, which provides global network bandwidth savings. However, this gain comes at the expense of data security. Indeed, clients may observe the network traffic between the DP and the SS, or have the opportunity to corrupt or replace the DP software. Such a solution protects efficiently the storage system solely against attacks based on backup time observation.

A deduplication proxy collocated with the storage server:

If the DP is physically collocated with the storage server, then even if clients do not upload more than once the same file to that location thanks to the intra-user deduplication, duplicates of a file owned by other clients will still have to be transferred over the network to reach that location before the inter-user deduplication can be applied. This is clearly not the most efficient choice in terms of bandwidth savings. On the other hand, data security is not affected by this solution.

Deduplication proxies hosted by independent nodes: We suggest that the two-phase deduplication relies on independent nodes to host the DPs. We argue that such nodes should be secure, physically out of reach of clients so that they can not observe the network traffic between a DP and the SS, but at the same time close enough to clients in order to improve the network bandwidth savings. We believe that to locate such nodes one could adopt a similar strategy to what is done in the field of Content Delivery Network (CDN) [START_REF] Pallis | Insight and perspectives for content delivery networks[END_REF]. In order to minimize data access latencies and network bandwidth consumption toward content servers, cache servers are deployed in strategic locations in the Internet infrastructure as close as possible to the clients to satisfy their requests close to them [START_REF] Huang | Understanding hybrid CDN-P2P: why Limelight needs its own Red Swoosh[END_REF]. For instance, an interesting approach would be to use the Points of Presence (POPs) of the ISP as secure nodes to host the DPs and associate them to clients accessing to Internet through them [START_REF] Meye | Toward a distributed storage system leveraging the DSL infrastructure of an ISP[END_REF]. This might also allow CSPs to cache files in the DPs in order to minimize the access latencies of subsequent get operations on these files.

B. Limitation of allowing the inter-user deduplication

In this section we discuss the potential danger of a true inter-user deduplication regarding data confidentiality, and provide insights to deal with them. Allowing the inter-user deduplication on encrypted files gives the opportunity to determine that two equal ciphertexts originate from the same plaintext. This can be exploited by the CSP since given a file or just its identifier, the CSP can determine whether this file already exists in the storage system and identify the clients who have uploaded it. Moreover the CSP is able to perform brute force attacks on file contents even if their files are encrypted with a convergent encryption [START_REF] Bellare | Dupless: Server-aided encryption for deduplicated storage[END_REF], [START_REF] Xu | Weak leakage-resilient client-side deduplication of encrypted data in cloud storage[END_REF]. Recall that in our proposition, the inter-user deduplication is unnoticeable to clients so these limitations are only applicable to the CSP. Nevertheless, one may find in such an approach an interesting property for the CSP to detect illegal files in its storage system or/and to respond to judicial inquiries for example.

Countermeasure: A strategy to protect files against such honest but curious CSP would be to encrypt files using private encryption schemes. For example, individuals may use personal keys in the file encryption process. In the case of a group of clients or an enterprise, a key server that does not belong to the CSP can be used to manage the encryption keys so that all the clients of the key server will encrypt a given file with the same specific key [START_REF] Bellare | Dupless: Server-aided encryption for deduplicated storage[END_REF], [START_REF] Liu | Policy-based de-duplication in secure cloud storage[END_REF]. However it will make possible the inter-user deduplication solely within the members of the group or the enterprise and would reduce the storage space savings of the CSP since a given file encrypted with different keys would result in different ciphertexts. A data deduplication process independent of the owners (i.e. individuals, groups or enterprises using different key servers) would be impossible.

VI. RELATED WORK

To deal with the security issues introduced by a clientside and inter-user deduplication, a method called randomized solution is proposed in [START_REF] Harnik | Side channels in cloud services: Deduplication in cloud storage[END_REF]. This solution defines a random threshold for each file in the storage system which corresponds to the number of different clients that have uploaded this file. Each time a client uploads for the first time a file, a counter associated with this file is created and initialized to 1. As long as the counter is under the threshold, deduplication is not applied. When the counter reaches the threshold, the inter-user deduplication is activated and applied to all the subsequent uploads of that file. This solution protects a file as long as its threshold is not reached. As soon as the system enables deduplication on a file, it becomes vulnerable. In [START_REF] Storer | Secure data deduplication[END_REF], the authors propose a deduplication method that is secure against targeted-collision attacks. Similarly to our method, a file identifier is a hash value of the file content so it is simple to check the consistency of a file and its claimed identifier. However, this method does not address the others types of attacks mentioned in Section I. In [START_REF] Heen | Improving the resistance to side-channel attacks on cloud storage services[END_REF], the authors propose a gateway-based deduplication scheme which relies on users gateways to run the deduplication process. In order to mitigate the attacks based on network traffic monitoring, gateways send a random network traffic compounded of encrypted packets with a Time-To-Live (TTL) parameter equal to 1. On the other hand, this method does not take into account neither backup time observation attacks, nor the possible corruption of the deduplication software module by the gateway owner. Several additional works suggest the notion of Proof Of Ownership (POW) [START_REF] Pietro | Boosting efficiency and security in proof of ownership for deduplication[END_REF], [START_REF] Halevi | Proofs of ownership in remote storage systems[END_REF], [START_REF] Mulazzani | Dark clouds on the horizon: using cloud storage as attack vector and online slack space[END_REF], [START_REF] Ng | Private data deduplication protocols in cloud storage[END_REF], [START_REF] Zheng | Secure and efficient proof of storage with deduplication[END_REF] to face the attacks based on manipulation of data identifiers. A proof of ownership allows a client to prove that he/she actually owns the file corresponding to the identifier presented to the storage server. However, it does not address the issues caused by attacks based on network traffic or backup time observation that are performed by adversaries that actually own the files corresponding to the identifiers that they present to the storage server. Some works rely on specific encryption schemes to provide data confidentiality and deduplication against honest but curious CSPs [START_REF] Bellare | Dupless: Server-aided encryption for deduplicated storage[END_REF], [START_REF] Bellare | Message-locked encryption and secure deduplication[END_REF], [START_REF] Liu | Policy-based de-duplication in secure cloud storage[END_REF], [START_REF] Xu | Weak leakage-resilient client-side deduplication of encrypted data in cloud storage[END_REF]. Table . I shows a comparison of some related work and our proposition regarding the storage space and network bandwidth savings, and the protection against the attacks mentionned in Section I. Compared to all the previously cited works, our two-phase deduplication method addresses all the attacks presented in Section I, and to the best of our knowledge this is the first one to achieve it.

VII. CONCLUSION AND FUTURE WORK

In this paper, we have presented a two-phase deduplication scheme that (i) ensures that a client actually owns the file he/she wants to store by applying an intra-user deduplication on the client side (ii) ensures that a file corresponds to its claimed identifier through a control by a deduplication proxy located between clients and the storage server and (iii) applies an inter-user deduplication on the deduplication proxy side that makes this inter-user deduplication unnoticeable to clients by adding some delay to put operations so that the length of a file upload is indistinguishable from an upload of its reference. Our method provides protection against attacks from malicious clients, global storage space savings to the CSPs thanks to the inter-user deduplication, per-client bandwidth network savings between clients and the deduplication proxies, and global network bandwidth savings between the deduplication proxies and the storage server.

For future works, we plan to address the confidentiality issues against attacks that can be performed by the CSP. We also plan to extend our solution so that encrypted decryption keys can also be deduplicated without jeopardizing security properties. We will also consider how to extend the deduplication in our scheme to a block level granularity.

Fig. 1 :

 1 Fig. 1: Architecture of the two-phase deduplication scheme.

Fig. 2 :

 2 Fig. 2: A PUT operation

Fig. 3 :

 3 Fig. 3: A GET operation.

Fig. 4 :Fig. 5 :

 45 Fig.4: Average delays observed during a put operation in a classic system with no data encryption and in our system with data encryption. Most of the overhead introduced by our solution is due to cryptographic operations which are necessary to ensure data confidentiality.

Fig. 6 :

 6 Fig.6: Performance comparison between a classic system with no data encryption where an inter-user deduplication is applied upon a put operation and our proposition with data encryption where an intra-and inter-user deduplication are applied. Most of the overhead introduced by our solution is due to cryptographic operations which are necessary to ensure data confidentiality.

TABLE I :

 I A comparison between some related works and our proposition.

	Approaches	Storage space savings	Network bandwidth savings	Protection against clients attacks based on data identifier manipulation	Protection against clients attacks based on network traffic observation	Protection against clients attacks based on backup time observation	Protection against honest but curious CSP
				No more protection when	No more protection when	No more protection when
	Harnik et al. [5]	Global savings	Global savings	the inter-user	the inter-user	the inter-user	NO
				deduplication is enabled	deduplication is enabled	deduplication is enabled
	Storer et al. [7]	Global savings	Global savings	Protection only against targeted collision attacks	NO	NO	NO
	Proof of ownership [11], [4], [14], [16]	Global savings	Global savings	YES	NO	NO	NO
			No bandwidth savings
			between the client and the	Limited to the ability of	Limited to the ability of
	Heen et al. [12]	Global savings	gateway but global bandwidth savings	attackers to monitor the traffic going through the	attackers to corrupt or replace the software	NO	NO
			between the client and the	gateway	module in the gateway
			storage server
		Global savings only for	Global savings only for		Online brute force attacks	Online brute force attacks
	Bellare et al. [8]	the group of users using	the group of users using	NO	are slowed using a	are slowed using a	YES
		their client solution	their client solution		requests rate limitation	requests rate limitation
	Xu et al. [15]	Global savings	Global savings	YES	NO	NO	YES
		Global savings only for	Global savings only for
	Liu et al. [13]	the group of users using	the group of users using	NO	NO	NO	YES
		their client solution	their client solution
	Our proposition
	with DP on the	Global savings	Global savings	NO	NO	YES	NO
	client
	Our proposition with DP on the storage server	Global savings	Per-client savings	YES	YES	YES	NO
			Per-client savings
	Our proposition with		between clients and the
	DP on an independent	Global savings	DP, and global savings	YES	YES	YES	NO
	node		between the DP and the
			storage server

"The digital universe decade. Are you ready?", by John Gantz and David Reinsel, IDC information, may

http://www.mongodb.org/

The encryption key encryption/decryption is negligible (around 0.75 ms) and is not visible on Figures4-6because of the figure scale.


Roberto G Cascella

Stefania Costache

Florian Dudouet

Filippo Gaudenzi

Yvon Jegou

Christine Morin

Multi-Cloud Portable Application Deployment with VEP

Keywords: Cloud computing, standards, resource management, interoperability, distributed application deployment

Leveraging the plethora of available Infrastructure-as-a-Service (IaaS) solutions proves to be a hard task for users who should face the complexity of dealing with heterogeneous systems, either in terms of resources or APIs. Application portability is the mean to reduce the burden of adapting applications for specific IaaS types and escape potential vendor lock-in. The Virtual Execution Platform (VEP) is a cloud middleware software that interfaces multiple IaaS clouds and presents end-users with an interface facilitating deployment and life cycle management of distributed applications made up of several inter-networked virtual machines. This paper presents the design of VEP and experimental results that evaluate its scalability in deploying applications on OpenNebula and OpenStack clouds.

Introduction

Recently, cloud computing has seen a tremendous growth with its increasing adoption both in industry and in academia. Cloud computing relies on virtualization technologies, which offer several advantages over traditional data centers. On the one hand users can move their applications to the cloud freeing themselves from the control and management of the infrastructure so that they can focus on the deployed services. On the other hand they can rent resources of cloud providers only when needed according to a pay-as-you-go pricing model reducing the cost of the infrastructure.

Although the cloud market is expanding fast, its growth may soon be hindered by different user concerns regarding lock-in within a single cloud commercial offer, data privacy issues and lack of performance predictability. In a nutshell, users might lose confidence in the model and services offered by a cloud provider. These issues are more pronounced for SMEs, which are interested in using the cloud technology, since they cannot afford the initial barrier cost to acquire their own datacenters, while they fear moving entirely their business in the cloud without guarantees.

Cloud lock-in makes the deployment of applications on different providers difficult for users. This complexity comes from the fact that users must customize the application and its Virtual Machine Images (VMI) to a specific Infrastructure-as-a-Service (IaaS) type used by cloud providers. When the user wants to switch from a cloud provider to another, she has to repeat this customization, making difficult to escape vendor lock-in and limiting the portability of the application. However, IaaS cloud interfaces and management software are evolving, making the repetition of the customization step and the deployment of portable application hard to achieve. Many standards are now flourishing to facilitate interoperability across different cloud providers and improve the portability of applications. The European Commission has seen the need to coordinate the jungle of standards to avoid the fragmentation of the digital market with the creation of a new Cloud standards co-ordination Task Group within ETSI [START_REF]Cloud standards coordination[END_REF].

Offering dependable services on top of a unreliable physical infrastructure is both a challenging task and an important feature to make cloud computing attractive for users and organisations. Hence, the cloud provider is not only charged with the complexity of managing a potentially distributed infrastructure and dispatching the virtual machines (VMs) of the applications to the physical resources, but with the need to offer guarantees to customers transparently. This implies ensuring the availability of the computation resources and having strict guarantees specified in a negotiated Service Level Agreement (SLA). Deploying applications under a SLA will make cloud computing a valid alternative to private data centers responding to users requirements in terms of availability, dependable application execution, and security. This paper presents the Virtual Execution Platform (VEP) system, an open source management middleware for IaaS clouds that addresses the cloud lockin and dependability problems. From the end-users perspective, VEP eases the deployment of distributed applications under the constraints of negotiated requirements, and at the same time offers advance reservation and pro-active fault tolerance services. From the cloud provider administrator point of view, VEP provides a REST interface [START_REF] Fielding | Architectural styles and the design of network-based software architectures[END_REF] and a simple GUI for administrators to manage their data centers.

VEP novelty comes from the fact that it relieves users from adapting their applications to the used IaaS, thus enabling multi-cloud portable application deployment. Portability is achieved by hiding the complexity of heterogeneous IaaS clouds: users have to specify one application description document, in an OVF [START_REF] Crosby | Open Virtualization Format Specification DSP0243 1[END_REF] format, that will be further used to deploy the application on different heterogeneous clouds. This makes possible in practice to use an OVF based application marketplace, where users can look for applications or submit their own. Moreover, VEP allows users to specify Service Level Agreement (SLA) terms. These terms can include constraints regarding the used application resources, e.g., in terms of node placement and data geographical location, specified times for starting applications, which are further enforced through advance reservation. Then, the VEP ensures that the providers' resources are utilized as needed for offering an elastic and dependable cloud service to customers. The primary use case of VEP is the Contrail [START_REF] Cascella | Contrail: Distributed application deployment under sla in federated heterogeneous clouds[END_REF] system, which develops an open source integrated approach to virtualization aiming at offering services for federating IaaS clouds and Platform-as-a-Service (PaaS) services on top of federated clouds. VEP manages the cloud provider services exposing the same API to the component offering federation services, thus enabling the deployment of an application over several heterogeneous cloud providers in a transparent way. As it provides a simple interface to access multiple IaaS cloud at the same time, VEP can also be used by PaaS providers. Developers can now focus on developing their services without the need of managing the IaaS complexity and the different heterogeneous solutions.

This paper is organized as follows. Section 2 describes related work. Section 3 gives an overview of VEP and its architecture and features. Section 4 presents results of running VEP on the Grid'5000 testbed [START_REF] Bolze | Grid'5000: A large scale and highly reconfigurable experimental grid testbed[END_REF] on top of two IaaS clouds (OpenNebula and OpenStack) and the Contrail use case for multi-cloud support. Finally, Section 5 concludes the paper and discusses future improvement directions for VEP.

Related Work

Very few propositions currently exist to manage the whole application lifecycle at the IaaS level while offering portability support and resource placement under SLA terms.

The DMTF Cloud Infrastructure Management Interface (CIMI [START_REF] Davis | Cloud Infrastructure Management Interface (CIMI) Model and REST Interface over HTTP DSP-0263[END_REF]) model defines a framework for the application life cycle management. CIMI applications can be generated from an OVF document but no support for SLAs is currently integrated. VEP implements part of the CIMI standard and extends it with SLA support. The OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA [START_REF]OASIS: Topology and Orchestration Specification for Cloud Applications Version 1[END_REF]) standard is also focusing on a multi-cloud approach. The portability of cloud applications is achieved thanks to an interoperable description of application and infrastructure services, and there is the notion of SLA. In contrast with the purpose of VEP, TOSCA focuses more on the notion of service than on the cloud infrastructure management.

The CompatibleOne [START_REF] Compatibleone | The Open Cloud Broker[END_REF] project develops an open source cloud software for managing applications across multiple clouds supporting cloud brokering and cloud federations. CompatibleOne is a generic platform built upon OCCI where various cloud and service providers publish their offers and supports SLA negotiation and enforcement. No standards for applications description are currently supported.

VMware vCloud Suite [START_REF]VMware: vCloud Suite for Cloud Computing & Cloud Management[END_REF] is a proprietary integrated solution for building and managing a complete cloud infrastructure. Applications in vCloud are formatted in the OVF standard but there is not an integrated support for SLA. RightScale [3] is another proprietary cloud management platform that offers portability by automatically configuring the application for a specific cloud. The main advantage of VEP over this solution is the open source approach.

VEP -Virtual Execution Platform

VEP [START_REF]VEP: Virtual Execution Platform[END_REF][START_REF] Harsh | Using open standards for interoperability issues, solutions, and challenges facing cloud computing[END_REF][START_REF] Jegou | Managing OVF applications under SLA constraints on contrail virtual execution platform[END_REF] is a cloud middleware software that interfaces IaaS cloud providers offering users a seamless way of managing multiple heterogeneous clouds. Cloud providers might have different means to manage VMs or networks, different image formats that can be deployed on a physical host, different interfaces, or different contextualization methods for the physical resources. VEP provides a uniform way of representing and managing the resources of a cloud provider.

VEP sits on top of IaaS management platforms such as OpenNebula, Open-Stack or any IaaS cloud providing an OCCI or EC2 interface. Users interact with VEP to deploy and manage their applications as a whole, while administrators use it to configure the IaaS cloud and limit the user access rights.

Application Description

In this section we describe how an application is described by the user and then how it is represented in VEP.

OVF description. To deploy an application in VEP, the user specifies the application characteristics in a document [START_REF] Crosby | Open Virtualization Format Specification DSP0243 1[END_REF] edited in OVF format, i.e., a format for the packaging and distribution of software to be run in VMs. This OVF format allows users to deploy applications on heterogeneous clouds as it is not tied to any particular hypervisor or processor architecture. The user can use the OVF document to communicate to VEP the following information:

-References to external files necessary to build the application, e.g., disk images. These references can be a filesystem path or a URL; -VM disk images together with their image format; -Shared storage to be mounted in the VMs; -Virtual networks to be used by the VMs; -VM templates defining the virtual hardware of the VMs, the VM disk images and the networks connected to the VMs; -Virtual hardware specification,e.g., number of processors and cores, memory size, disks, network interfaces, etc. To improve portability, the format also supports alternative hardware descriptions, allowing the IaaS provider to select the configuration it supports, e.g., the disk image format; -Contextualization data to be passed to the VMs at boot time, e.g., public key, IP, etc.

Resource Handlers. Using the OVF document, VEP deploys the user's application in a virtual execution environment, i.e., a generic platform composed of virtual resources, e.g., VMs, network or storage. However, to be deployed on the infrastructure, this virtual execution environment needs to be mapped to a set of virtual resources provided by the IaaS management platform. These resources are specified in VEP through virtual resources handlers, which basically define different classes of resource configurations, by following the DMTF's CIMI [START_REF]Cloud Infrastructure Management Interface (CIMI) Model and RESTful HTTP-based Protocol, An Interface for Managing Cloud Infrastructure[END_REF] standard 1 . Currently, VEP supports three types of handlers:

1 Compatibility tests with the standard are currently under evaluation. -VM handlers describe the computational resources amount (e.g. memory, disk space, number of cores and core frequency) assigned to a VM; -network handlers describe a specific network setup; -storage handlers specify the type of storage for the application's data (e.g., NFS or XtreemFS/GAFS [START_REF] Stender | Requirements and Architecture of the Global Autonomous File System[END_REF]). VEP handles the allocation of resources on the IaaS cloud by using these specified resource handlers. Multiple applications can be deployed inside the same virtual execution environment. A user can define her own execution environments using predefined resource handlers.

Constraint description. VEP allows users to also specify SLAs regarding the resources allocated to their applications, or choose from default ones. These SLAs are expressed as constraints on the virtual execution environment in which the application runs. Different types of constraints are supported in VEP concerning the placement or the number of virtual resources which can be allocated. For instance, constraints can specify the affinity to allocate VMs close to each other, e.g. on the same node or rack, in order to improve their network communication, or anti-affinity to increase dependability, for instance to place VMs on different data centers or countries. These constraints together with the virtual environment, in which the application runs, compose a Constrained Execution Environment (CEE). These constraints are also applied to the virtual resource handlers, composing the CEE handlers. When an application is deployed, one of the CEE handlers is used to define the physical resources to allocate to the application's VMs. This CEE handler can be explicitly specified in a deployment document or derived from default mapping rules of the application or of the CEE.

Figure 1 illustrates a CEE and the relation between constraints, virtual resource handlers and the OVF description. In this figure there are two constraints: sameSwitch and 10Gb. The constraint sameSwitch is linked to all handlers of the CEE. To enforce this constraint, all physical resources allocated by the CEE must be connected by the same L2 switch. The constraint 10Gb is linked to the handler largeVolune and to the handler l2Net: the physical volume resource where the volume is allocated must be connected to the L2 switch at 10 Gb/s.

Basic User-VEP Interaction

To run an application on VEP, a user has to perform three main steps: (i) submit a document containing a CEE description, using the OVF format [START_REF]DMTF: Open Virtualization Format Specification[END_REF] and possibly describing virtual resource handlers and constraints, i.e., SLAs, for the application resources; (ii) submit a deployment document to VEP and ask it to add a number of virtual resources to the application using the previously mentioned constraints; (iii) and then ask VEP to start the application.

VEP selects a set of nodes from the IaaS cloud on which application VMs are placed, and then it instructs the IaaS cloud manager to start the VMs. For starting the application, VEP might also perform additional operations. For example, a user might specify in the OVF document a path for her own VM image. In this case, VEP has to upload the user image to the IaaS cloud data storage. This operation is made at the first deployment. Once the image is added and stored, it is kept until the application is deleted. During the application runtime, the user can ask VEP to start more VMs, by submitting another deployment document, or stop the application.

VEP Architecture

VEP has been designed to be highly modular in nature with well defined internal APIs to facilitate the reuse of the software and/or updates. The VEP architecture, depicted in Figure 2, is composed of two main modules: the VEP-Core and the Scheduler. The VEP-Core represents the interface between the users and the IaaS cloud providers by managing user accounts and the representation of the IaaS resources. The Scheduler is in charge of scheduling the deployment of an application and allocating the physical resources such that users' constraints are satisfied. We describe next these two components.

VEP-Core. VEP-Core is composed of a set of services, which are offered to users, and a set of internal modules. A set of native cloud drivers are used by the VEP-Core modules to communicate with the IaaS management platform.

Users can access the VEP-Core services based on their defined role in VEP: end-user and administrator. The administrator has access through a GUI interface to a set of Administrator Services.These services allow her to add datacenters to the VEP managed clouds and configure their resources, e.g. available nodes and the network topology. The user has access to a set of User Services, through a GUI interface, and a RESTful API. These services allow her to define application description/deployment documents, deploy and manage applications. The VEP-Core also relies on an Authorization/Authentication (Authz/Auth) service which authenticates users in the system. The authentication of users relies on a username and password which are then used to obtain X.509 certificates. The Authz/Auth module of VEP uses these certificates to verify internal access policies that allow a user to share or protect her information/applications. Applications are managed by the Appliance Manager service. This module handles the application life-cycle, from submission, deployment to shutdown. An OVF Toolkit parses the application's OVF document to determine which virtual resources are part of an application and the location of the VM images, and stores this information in a database (DB Engine). The CIMI Manager parses the application description and creates the virtual resource handlers. These handlers, together with the user-specified constraints are submitted to the Scheduler, to allocate physical resources and start application's VMs. Finally, the VEP-Core users a GAFS Client to provide users shared XtreemFS storage that can be accessed from the application's VMs.

VEP-core Scheduler

Scheduler. The Scheduler is an independent module of VEP and provides a scheduling service to VEP through a REST interface. The core of the Scheduler is represented by the Scheduling Engine, which allocates physical resources to VMs by communicating their placement to the IaaS management platform. A Constraints Manager enables placement constraints, as defined in the user CEE. To provide guarantees about resource availability, the Scheduler also handles advance reservation of resources before application deployment through its Reservations Manager service. Reservations are stored in a database so that VMs placement can be done according to reservation requests, resource availability and user-defined constraints.

VEP Features

We have previously described the architecture and services of VEP. This section presents first the unique selling proposition of the VEP system: multi-cloud (portability) and SLA support. Then the main features are summarised at the end of the section.

Portability support. VEP hides the complexity of heterogeneous IaaS clouds from the user, as the same application description (OVF) and constraints (CEE) are used to deploy an application regardless of the underlying IaaS platform. End-users only need to submit the OVF document describing the whole application and create the CEE; then, VEP is in charge of allocating resources and start the application. The adoption of the OVF format by VEP also improves the user's application portability with existing commercial systems from VMware, IBM, Oracle, Red Hat, systems that also support OVF.

SLA support. VEP provides users with resource SLA support during their application deployment through Contrail Constrained Execution Environments (CEEs), that allow users to specify constraints regarding their desired resources. These CEEs can be derived from a negotiated SLA or made available as templates ready to be instantiated by users. The CEE can also be used to define monitoring configurations. This feature can be later exploited to evaluate whether SLA constraints are enforced; at the time of writing SLA enforcement is not currently supported and left for future work.

As part of the SLA support, VEP can also facilitate the elasticity of applications, i.e., by adding or removing some of their resources, as required to meet their performance objectives. The elasticity support is facilitated by VEP through supporting two deployment modes of OVF applications: implicit and controlled. In an implicit mode, all OVF virtual resources are deployed and started; in a controlled mode a user can explicitly specify which and how many OVF virtual resources listed in a deployment document should be started. By submitting a new deployment document to an existing application, the user can add more resources during the application runtime.

In the previous paragraphs, we have presented the VEP support for portability and SLAs through CEEs. Other features of the Contrail VEP not extensively discussed in this section are: partial application deployment to allow a user to link the deployed application with an existing one; advance reservation to guarantee resource provisioning in the future; design support for application snapshots to improve dependability for long running applications.

Validation

In this section we describe the validation of VEP. We first discuss the evaluation of the prototype on a real testbed and then a use case of it.

Evaluation on the Grid'5000 Testbed

We deployed VEP [START_REF]VEP: Virtual Execution Platform[END_REF] on the Grid'5000 testbed on top of two different IaaS cloud provider systems. The goal of this evaluation is to show that VEP can be used on top of different clouds and to measure its overhead.

Implementation. VEP is implemented in Java and consists of approximately 30,000 lines of code. Currently, VEP's scheduler places VMs on the nodes in a round-robin fashion, starting from a randomly picked node. VEP stores all the user and application information in a database, for which, MySql is used. Experimental Setup. We deployed VEP on the Rennes site from Grid'5000 on 30 nodes of two clusters: parapide and parapluie. The parapide cluster is composed of nodes with Intel Xeon L5420 processors (8 cores) and 32 GB of RAM. The parapluie cluster is composed of nodes with AMD Opteron(tm) 6164 HE processors (24 cores) and 48 GB of RAM. All the nodes are connected through a Gigabit Ethernet network. As an IaaS cloud manager we used OpenNebula 4.2 and OpenStack Grizzly. For both OpenNebula and OpenStack we used the default configuration. Optimizing the configuration of these software stacks is outside the scope of this paper. By default, as a storage for VM images, Open-Nebula uses a NFS server while OpenStack uses the local filesystem provided by its datastorage service, Glance.

To run an application on VEP we set up a VM disk image of 4.33 GB in QCOW2 format. In our experiments we submitted an OVF to VEP that instructs it to deploy VMs with this disk image. This OVF was used to create an application CEE composed of VMs with a capacity of 1 virtual core and 800 MB RAM.

Results. To measure the overhead of VEP, we deployed it on top of Open-Nebula and OpenStack and started applications composed of 1 to 100 VMs. For these experiments, the only impact on the results is the size of the VM image and not the type of application. We measured the time required to start the application using VEP (VEP create time), as well as the time required by the IaaS management platform to deploy the VMs (IaaS create time). We define these two time intervals as follows:

-VEP create time is the time interval from the application submission request registered by the VEP scheduler to the last VM boot; -IaaS create time is the time interval from the processing of the first VM submission by the IaaS management platform to the last VM boot.

Figure 3 shows the time intervals needed for deploying an application composed of different number of VMs. We notice that, the VEP create time increases slowly, compared to the number of VMs to be deployed. This is due to the policy of the VEP scheduler and by fact that the IaaS management platform can deploy the VMs on the nodes in parallel. The difference between the VEP create time and the IaaS create time, which in our case is approximately 100 seconds, is mostly represented by the time required by VEP to upload the VM image to the IaaS storage. Other operations are also performed, like checking user privileges, inserting application's information in the database and sending the appropriate requests to the IaaS management platform. Nevertheless, their cost is negligible. The IaaS create times are highly dependent on the used IaaS management platform. The main difference between the two IaaS management platforms is given by the mechanisms used to copy the VM image to the node on which the VM is booted. In OpenNebula, a frontend process connects to the nodes and creates a qcow image from a base image that is hosted on the shared NFS server. In OpenStack, each node downloads images through HTTP from the Glance service hosted on the frontend, and then a qcow image is created locally. In this case, the network becomes a bottleneck and leads to high VM deployment times.

We also measured the time required by VEP to process the different application operations, as seen by the user. Figure 4 shows the time for the usual operations: (i) deploying, (ii) starting, (iii) and stopping an application. We haven't included the time for submitting a CEE, as it is negligible. For deploying and starting an application, the user sees the cost of authentication, checking her constraints and storing the information in the database. The cost of starting the application is not noticed by the user, as this operation is done asynchronously by VEP. For stopping the application, the user notices the time required by VEP to delete the VM information from its database and to release the used resources from the IaaS management platform.

VEP Use Case: the Contrail Project for Multi-cloud Support

Contrail [START_REF] Cascella | Contrail: Distributed application deployment under sla in federated heterogeneous clouds[END_REF] is a European project which offers services for federating IaaS clouds, and Contrail PaaS (ConPaaS) services on top of federated clouds. The user relies on the Contrail federation to manage the access to individual cloud providers, such that an application can be seamlessly and automatically deployed over a multitude of heterogeneous providers. The providers can rely on different cloud technologies, exploit different hardware, or offer different types of guarantees.

The VEP system is integrated in the Contrail software stack and manages the Contrail cloud provider. The role of VEP is to seamlessly integrate the provider resources within the Contrail federation and provide virtualized distributed infrastructures for the deployment of end-user applications independently from the underlying platform (currently OpenNebula or OpenStack).

VEP offers to Contrail a reliable application deployment platform, which is resilient to operational failures and which ensures that an application is deployed respecting QoS requirements, negotiated between the user and the Contrail federation. The use of VEP allows to deploy a distributed application under the terms of a SLA over the resources of any of the supported IaaS providers. In Contrail, the elasticity of the application is also ensured by monitoring the usage of the resources stated in a negotiated SLA, both within the cloud provider infrastructure and at the federation level. VEP receives direct instructions to add or remove resources.

The features and the degree of interoperability that the Contrail federation can exploit on each single cloud provider depend on the specific functionalities implemented at the cloud provider level. Interoperability is achieved through the VEP component.

VEP can offer multi-cloud support to PaaS services via the RESTful API. In the framework of the Contrail project, ConPaaS could use VEP to deploy PaaS services on any supported infrastructure.

Conclusion

In this paper we presented the VEP service, which considerably facilitates the deployment of distributed applications on heterogeneous clouds. VEP takes as input applications described as OVF packages and automates their deployment on IaaS clouds. From a unique OVF description cloud customers can deploy their applications on any IaaS cloud supported by the VEP service. Moreover, VEP contributes to increasing the confidence that customers put in cloud computing by taking into account SLA terms when deploying an application. Among SLA terms supported, we can cite virtual machine placement in the datacenter (cluster, rack, server) and data geographical location. VEP provides unique features like resource advance reservation and support for elasticity.

The current version of VEP has been deployed on OpenNebula and Open-Stack IaaS cloud management systems and tested on the Grid'5000 testbed. As a use case, VEP was integrated in the Contrail system. To our knowledge, VEP is one of the first systems implementing a CIMI-like cloud management interface. Through its features, VEP paves the way to an open cloud market by breaking the vendor lock-in. Moreover, VEP features make possible the usage of an OVF based application marketplace, where users can look for applications or submit their own. In our future work, we plan to interface VEP with public clouds such as Amazon EC2 and with any cloud providing an OCCI interface. We also plan to include mechanisms to snapshot applications for fault tolerance and migration purposes, and monitoring mechanisms to enforce SLAs with automatic elasticity.

Fig. 1 .

 1 Fig. 1. Constrained Execution Environment (CEE)

Fig. 2 .

 2 Fig. 2. VEP architecture

Fig. 3 .

 3 Fig. 3. Start time of an application composed of different numbers of VMs on (a) OpenNebula and (b) OpenStack.

Fig. 4 .

 4 Fig. 4. Time for processing a user request composed of different numbers of VMs.

Acknowledgments This work is partially funded by the FP7 Programme of the European Commission in the context of the Contrail project under Grant Agreement FP7-ICT-257438. The experiments presented in this paper were carried out using the Grid'5000 experimental testbed, being developed under the INRIA AL-ADDIN development action with support from CNRS, RENATER and several Universities as well as other funding bodies (see https://www.grid5000.fr).