WO2017153833A1

WO2017153833A1 - A system for cloud computing and/or storage using a plurality of independent clouds

Info

Publication number: WO2017153833A1
Application number: PCT/IB2017/000235
Authority: WO
Inventors: Maurizio Michele ZUZZARO
Original assignee: Vague T & D SA
Current assignee: Vague T & D SA
Priority date: 2016-03-09
Filing date: 2017-03-08
Publication date: 2017-09-14
Anticipated expiration: 2018-09-09
Also published as: ITUA20161471A1

Abstract

A method of storing and/or processing files on a plurality of independent clouds (Ca...Cn) includes, uploading the file to the clouds (100) by dividing the file into a plurality of fragments (104); associating the file with redundancy information (106), encrypting the file and the redundancy information (107); and uploading (109-115) the file fragments and the redundancy information to different clouds.

Description

TITLE: A SYSTEM FOR CLOUD COMPUTING AND/OR STORAGE USING A PLURALITY OF INDEPENDENT CLOUDS

DESCRIPTION

TECHNICAL FIELD

This invention relates to information processing and/or storage systems utilising the so-called "clouds", and more particularly it concerns a method of processing and/or storing information in a manner subdivided among a plurality of mutually independent clouds or cloud systems, a device for implementing the method and a computer -program product that can be loaded into the memory of a processing unit and includes software code portions for carrying out said method when the product is executed on the processing unit.

BACKGROUND OF THE INVENTION

As known, the term "cloud" denotes a set of information technology infrastructures (hardware and software) remotely located relative to, the users and intended to provide the users with different services, such as information storage and/or processing, provision of information technology applications, and so on.

Hereinafter, for the sake of simplicity, the term "storage" will be used, but it must be understood that this term encompasses all services allowed by cloud technology.

Cloud storage service is of particular interest since it dispenses the users with the need for accurately planning the information technology resources they may need and -f-or bearing the heavy investment outlays for the corresponding infrastructures. Moreover, the service offers a high flexibility and scalability of, the resources to be used.

Notwithstanding' this economic appeal, many potential users are reluctant to exploit those services for several reasons. Even assuming that the service provider is a reliable and honest organisation, and. neglecting the juridical problems (for instance related to the place of physical location of the infrastructures on which the data ^■ are stored, which determines the laws applicable in case of disputes between the user and the provider) , .cloud storage, in particular storage on a single public cloud, can give rise to problems especially concerning data security and confidentiality and accessibility to the stored data :

the user, by entrusting the data to the systems of a remote provider, loses the direct and exclusive control of the same data; moreover, the ' clouds are shared- systems and infrastructures used by multiple and changeable ^'users, who could have different or contrasting or competing ^■ interests and needs; it is therefore essential that the providers implement security mechanisms in order to ensure confidentiality and availability of the information stored on the cloud;

the selected service could be the final result of a chain of transformations of services acquired from other service providers, different from the .provider with which the user draws up the service contract; not always the user, in case of complex provider chains, could be able to know 'which one of the intermediate service providers has access to certain data; the- service could be occasionally degraded in case of high traffic peaks or even be unavailable for instance . in case of failures; thus, the user could be unable to carry out his/her activity for an indefinite time, which he/she can in no way influence .

PRIOR ART

^■ A usual solution to the problems of security and confidentiality of the information stored on a cloud and of accessibility to same consists in subdividing the information among a plurality of clouds managed by independent providers and. in associating the information with a suitable redundancy, so that the user can anyway retrieve the whole of the information even though, for some reason, part of it is lost or is inaccessible.

The solutions most commonly adopted to this aim transfer to the cloud environment the RAID (Redundant Array of Independent Disks) techniques standardised for distributed information storage on hard disks. Examples are disclosed in the article "The design of a redundant array of independent net-storages for improved confidentiality in cloud computing", M. G. Jaatun et al., Journal of Cloud Computing: Advances, Systems and Applications 2012, 1:13, or in patent applications US 2012/0137199 and US 2015/0381736.

In those known systems, the user can directly manage the storage operations, thereby eliminating the risks for the information security and confidentiality inherent in other solutions where management is entrusted to a centralised device.

Yet, in such systems, like in conventional RAID techniques based on hardware structures (hard disks), which: assume the use of disks having the same capacity, there is an ineffective resource exploitation when the clouds have different capacities: indeed, in such case, each cloud can be occupied only over a capacity corresponding to that of the cloud with minimum capacity, so that available space remains in the clouds with greater capacity, which space cannot be used and is wasted. Thus the user is compelled to rely on a greater number of providers, with a substantial cost increase.

Another drawback of the known solutions is their scarce flexibility since, after an initial choice of the clouds to be used, their number cannot be varied at will during the operations. Therefore, it is an object of the invention to provide a system for information processing and/or storage on a plurality of independent clouds, which obviates the drawbacks of the prior art.

SUMMARY OF THE _'INVENTION

According to the invention, this^, is achieved through a method wherein a phase of file upload to the clouds includes for each file, previously to a file division into fragments and to the fragment distribution among the clouds, the steps of:

checking the storage capacity available on all clouds to which a user has access;

selecting, for storing and/or processing the file, a cloud set that includes all clouds having available storage" capacity for the file or a subset of such clouds and may contain, for each file, a variable number of clouds;

nd wherein the division into fragments includes the tep of dynamically and automatically adapting the jmber and the size of the fragments to a current jmber of clouds in the set.^'

According to another advantageous feature, the method includes: encrypting the different file fragments with different encryption keys;

generating an authentication code for the data contained in each fragment;

creating a metafile containing the encryption .keys and the authentication codes;

uploading the metafile to all clouds in the set .

The invention also concerns a device for implementing the method and a computer program product to be loaded into the memory of a processing ¹ unit and including software code portions for carrying out the method when the product is executed on the processing unit. As used herein, the reference to such a computer program product is meant as being equivalent to the reference to a computer-readable medium containing instructions for controlling a computer system or device in order to coordinate the execution of the method according to the invention.

BRIEF DESCRIPTION OF THE FIGURES

The invention will be better understood from the following description of preferred embodiments made by way of non-limiting example with reference to the accompanying drawings, in which:

Fig. 1 is a basic block diagram of a- system for information storage on a plurality of independent clouds;

Fig. 2 is a logic diagram of a user terminal ;

Fig. 3 is a logic diagram of the association between a cloud portion and a user;

Fig. 4 is a flow chart of the operations for uploading a file to the clouds;

Fig. 5 is' a representation of the synchronisation between the devices of a same user;

Fig. 6 is a diagram of the subdivision of a file set among clouds of different capacities;

Fig. 7 is a diagram similar to Fig. 6, showing the subdivision of a file set among the clouds when a cloud is added;

Fig. 8 is a flow chart of the operations for downloading a file from the clouds; Fig. 9 is a flow chart of the operations for redistributing the files among the clouds when a cloud is removed;

Fig. 10 , is a diagram of the sharing of a file between two users;

Figs. 11A and 11B are flow charts of the file sharing operations for the proprietor user and the receiver user, respectively; and

Fig. 12 is a logic diagram of the logic unit managing cloud storage in a user terminal. DESCRIPTION OF THE PREFERRED EMBODIMENTS

Fig. 1 schematically shows a system 1 offering a storage information service on a plurality of independent clouds Ca ... Ch .... Cn to a plurality of users Ua...Um. The term "independent" means that, in general, different clouds are managed by different organisations, whereby each cloud Cj can represent one of the presently existing commercial services (e.g. Amazon S3, Google Drive, Dropbox ... ) .

Users Ui can access clouds Cj for storing and/or reading information through a communication network 2, e.g. the Internet. The invention is of particular interest when clouds Cj are public clouds, that is, they are not reserved to users belonging to a given organisation. Indeed, the problems of security, confidentiality and accessibility mentioned above are particularly felt in this context.

, Each user Ui represents one or more terminals capable of connecting themselves to the Internet, such as PCs, cellular phones, tablets etc. The different terminals can simultaneously access clouds Cj and they must be equipped with suitable APIs (Application Program Interfaces) for the cloud environment, allowing requesting the data and processing one or more services through a direct or an indirect interface. Generally, such APIs have functions of component creation, displacement or elimination (so called "provisioning" functions) and configuration functions (allotment or modification of the architecture attributes, such as security and network settings).

A given information set to be stored (hereinafter referred to as "file") is divided into a plurality · of fragments which are distributed among a plurality of clouds Cj with the modalities provided for by the RAID standards, possibly after having been associated with a redundancy and encrypted. Conversely, the user will recover the different fragments of a file from the clouds where he/she has stored them and will reconstruct the whole file, by exploiting the .redundancy to complete the file should some fragment be inaccessible.

The modalities of storing the fragments on the clouds are such as to optimise the efficiency of exploitation of the same clouds, as it will be described later on. ¹

The number of clouds among which a file will be distributed depends, inter alia, from the desired requirements of confidentiality and of security in case of failures. It is clear that the greater the number of clouds among which a file is distributed, the lower the probability that unauthorised people can reconstruct the whole . contents of the file or that failures or overloads in the clouds or the communication network affect a number of clouds (and hence of file fragments) such as to prevent recovery of the file itself.

A user terminal Ui will have the logic structure , depicted in Fig. 2. The terminal includes a processing^' unit 10 arranged to execute instructions necessary for implementing the method according to the invention, input/output devices 11 (such as keyboard, mouse, display, touch-screen display, etc.), data memory devices 12 acting as. a local store, a logic unit 13 for managing storage, and a working memory 14. Input/output devices 11 incorporate also the devices interfacing terminal Ui with network 2. The different elements are interconnected via a bus 15.

Unit 13 is the device for implementing the method according to the invention, and it may consist in a computer program product to be loaded into memory 14 and containing ^"software code for implementing the method according to the invention when the product is executed on processing unit 10. Unit 13 may also be defined as a computer-readable medium containing instructions for controlling processing unit 10 in order to coordinate the development of the method. The logic structure of unit 13 will be described later on.

Each cloud Cj will generally include a plurality , of data storage devices, interconnected by a network internal to the cloud itself. The physical structure and the organisation of a cloud are well known to those skilled in the art and are not of interest for the invention. At a logic level, as shown in Fig. 3, each user Ui will have at disposal, within each cloud Cj used, a memory area 20i for his/her data 21, which are associated with a metafile 22 which will be discussed later on. Tire space actually available for the data of users Ui will be the sum of the spaces on all clouds C , less the space occupied by the redundancies and the metafiles .

Fig. 4 shows process 100 for storing a file on the clouds. By way of example, it is assumed that RAID 5 technique is use for distributing the file, according to which technique a single redundancy information block (e..g. the parity) is associated with the file and is stored on a cloud different from the clouds used for storing the actual data. Moreover, it is assumed that the file upload to the clouds and the subsequent file recovery from the clouds ₍serve to keep a local store of the user synchronised with the remote store on the clouds.

The process is started for instance when a suitable routine on the user terminal detects changes in one or ^'more files in a certain working area. Once the files to be uploaded to the clouds have been identified, resources are requested from the clouds with which the user has made a service contact (step 101) and the memory capacity (or space) available on each of said clouds is checked (step 102) .

Once the information about the available capacity has been received from the clouds, the user chooses the clouds on which he/she wishes to store the file (step 103). All available clouds or only a subset thereof can be chosen. The next step (step 104) is the file division into NF fragments, having all the same size, number NF depending on number CA of the. selected clouds. More particularly, if' CA < 3, NF = CA, whereas if CA > 3, NF = CA - 1.

If CA > 3 (step 105, output YES), the parity is computed (step 106) . Actually, only if CA ≥ 3 the parity allows recovering the data in case of loss a fragment and can be stored on a cloud different from the clouds used for the data, as provided for by RAID 5. The parity is for instance computed for each fragment, e.g. as EX-OR, and the file parity is obtained from the fragment, parities, always as EX-OR. The parity block will have the same size as the file fragments and, for the purposes of the subsequent operations, it is handled like the file fragments. Subsequently (step 107), the NF file fragments and the parity block are encrypted.

Preferably, each fragment is encrypted with a different key. Thanks to the use of a plurality of keys, an unauthorised person can recover the whole file only if he/she can find all keys. Encryption ' is carried out with one of the algorithms conventionally used in the field, for instance algorithm SHA-256 (SHA = Secure Hash Algorithm) . Algorithm SHA-256 is disclosed for instance in document Federal Information Processing Standards Publication (FIPS PUB) 180-4 "Secure Hash Standard (SHS)", Information Technology Laboratory, National Institute of Standards and Technology, August 2015, available at site http: //dx. doi.org/ 10.6028 /N I ST. FIPS.180-4.

The keys will then be introduced into metafile 22 (Fig. 3) at the end of the file upload process.

Step 107 is directly reached from step 105 if CA < 3 (output NO of step 105) . In the alternative, this situation could be is signalled by the, program by means of an alarm, as a consequence of which a further cloud is added (step 119) so that the parity can be computed. According to the invention, besides data security through data encryption, also data authenticity is ensured (step 108) by using an authentication procedure such as HMAC (keyed-Hash Message Authentication Code) procedure. According to such a procedure, a signature is computed for each fragment by using a secret key identical for all files and all users. The signature is then stored in metafile 22. In the downloading phase, by applying again the algorithm, it is possible to verify that the data on the clouds have not been modified. In practice, the metafile ,is divided into blocks with length j bits. Then, the secret key K (known only to process management logic or program 13) is chosen and "signature" or code K' to be inserted into the metafile is generated according to the following rules:

K* = K if |K| = j bits

K ' = K + filling with zeroes if |K| < j bits

K' = H(K) if |K| > ^'j bits (H being the hash function) .

HMAC procedure is for instance described by H. . Krawczyk et al. in Internet Draft RFC 2104 "HMAC : Keyed-Hashing for Message Authentication", Internet Engineering Task Force (IETF), February 1996. At this point the data are ready for being uploaded to the clouds selected. Assuming that the parity block has been created, at step 109 a random number P ranging from 0 to CA-1 is computed in order to choose the cloud where that block will be stored. Then, beginning with the first cloud (j <- 0, step 110) and as long as there are available clouds (step 111, output YES), there is checked (step 112) whether the block to be uploaded is a file fragment (j ≠ P) or the parity (j = P) . In the first ^'case the block is uploaded to cloud CA ( j ) (step 113), whereas, in the second case it is uploaded to cloud CA(P) (step 114). After uploading of each block, j is incremented (step 115) and the operations are repeated for the subsequent cloud. When the clouds have been exhausted (step 111, output NO), 'there is checked (step 116) whether the metafile with the information about the data having been loaded already exists. The metafile exists (step 116, output YES) if the storage operation is not the first one performed by the user, and in such case the metafile is updated on all clouds (step 117). If the metafile does not exist ((step 116, output ^' NO), it is created (step 118) and uploaded to all clouds (step 117). The file uploading process thus ends.

It will be appreciated from the above description that , the number and the identities of the clouds having been chosen is an information remaining in possession of the file proprietor only, and that no element in the system takes part in the choice of the clouds or becomes acquainted with it during the process. Even if the encryption keys contained' in the metafile, are present in all clouds, it is extremely improbable that a malicious person accessing a cloud and being successful in decrypting the metafile can also recover the identities of the other clouds being used. Hence a higher security exists with respect to most known systems, where the clouds being used are fixed and are established in an initialisation phase.

The identities of the clouds chosen form a unique, key for access to the service, which key may be exchanged, preferably in encrypted form, among the devices or terminals of a same user Ui in order they can become quickly synchronised with one another. The exchange is schematised in Fig. 5, where Dl ... D5 denote the devices of user Ui.and AK is the unique key. Without use of the unique key, synchronisation could be a very complex operation, since the user can theoretically choose among an infinity of clouds.

Coming back to metafile 22, all data useful for reconstructing the original files are historicised therein. The metafile is replicated on all clouds of the user and is handled as any data file, with the only exception that it is not divided into fragments- in the process of upload to the clouds. Replicating the metafile on all clouds is important since otherwise, should the metafile be lost, recovering the files from the clouds would become practically impossible. The metafile is characterised by a "version" number that forms a reference index allowing checking, during data recovery from the clouds, the alignment between the local and the remote store.

The metafile could for instance include the following fields (for non-obvious fields, a definition is given) :

id (uuid, 16 bytes) ;

- parent Id (uuid, 16 bytes) : this field identifies the folder where the file is located and it is used in particular for files generated by mobile devices; name (string, variable size);

path (string, variable size): this field identifies the path where the file is located and it is used in particular for files generated by PCs;

type (int, 4 byte): file type (e.g. jpg, doc, xls ... ) ;

- createdOn (datetime, 9 byte) ;

- modifiedOn (datetime, 9 byte) ;

cloudEntries (variable size) ;

- KeyHMAC.

Each of the "cloudEntries", which · form the actual information content, has in turn the following structure:

entryld (uuid, 16 bytes);

provider (string, variable size):, this field identifies the cloud;

code (string, variable size);

index (int, 4 bytes) .

As mentioned before, according to the invention the distribution of the files and the fragments among the available clouds takes place so as to optimise exploitation of the memory spaces available in the clouds, in particular if the clouds have different capacities. Reference is made to the example depicted in Fig. 6, where it is assumed that seven files Fa, Fb...Fg are to be distributed among five clouds C1...C5.

For the first four files Fa ... Fd the check on the memory capacity available on clouds C1...C5 reveals that all five clouds have space for storing the files: the latter will therefore be divided into four fragments, respectively denoted Fxl...Fx4 (x = a...d) , and parity Px is computed for each file. The fragments of Fa are stored for instance on clouds C1...C4, whereas parity Pa is stored on C5. The fragments of Fb are stored for instance on . clouds CI, C2, C3, C5, ^'whereas parity Pb is stored on cloud C4, and so on. As stated before, the cloud where the parity of a file is stored is determined in random manner, hence parities Px are not necessarily stored on four different clouds, as shown in the Figure.

For file Fe, the check on the available space reveals that only clouds C2...C5 are capable of storing it, since -cloud CI is completely occupied by files Fa ... Fd or, at any rate, it has an available space (dashed area) insufficient for a fragment of file Fe . File Fe is therefore divided into three fragments, which in the example are stored on C2, C4, C5, whereas cloud C3 stores parity Pe . As said, in the conventional RAID technique, once the capacity of CI is exhausted, the space available on clouds C2...C5 could not be used, thus compelling the user to get further resources from other providers.

Storage of file Fe exhausts also the space on ■C5, and three clouds remain available. The subsequent file Ff is therefore divided into two fragments stored e.g. in C2, C3, whereas parity Pf (which is still computed since CA = 3) is stored on C4.

Lastly, when file Fg is to be stored, only clouds C2, C3 are available, and file fragments Fgl, Fg2 are stored there. The parity is no longer computed .

The broken lines denote the space available for further files, if any.

At any moment during the upload process, the user can decide to add a further cloud to those initially chosen. The corresponding procedure is shown in Fig. 7, assuming again that seven files Fa ... Fg are to be initially distributed among clouds C1...C5, of which cloud CI exhausts its capacity upon storage of file Fd. Tl, T2, T3 denote the instant at which process 100 (Fig. 4) is started for the first file Fa, the instant at which the capacity of CI is exhausted and the instant at which a further cloud C6 is added, respectively. It is assumed that all clouds C2...C5 remain available during period T2 - T3. For files Fa...Fe, the operations are therefore identical to those disclosed with reference, to Fig. 6. When file Ff is to be uploaded, four clouds are still available, and hence file Ff is now divided into three fragments Ffl'...Ff3'; the file parity is denoted Pf ' . Once the operations concerning Ff are over (instant T3), also cloud C6 becomes available. The subsequent file Fg is therefore divided into four fragments Fgl'...Fg4', which are stored e.g. on clouds C2...C5, whereas on cloud C6. there is stored parity Pg, which is now computed since CA > 2. For the subsequent files, if any, the described operations are repeated, by taking into account the possible filling/addition of other clouds.

The Figure clearly shows that the new cloud is used only for the files uploaded from instant T3 onwards, and that the files previously uploaded are not subjected to redistribution. The addition of the new cloud can be particularly advantageous in situations like that disclosed for file Fg in Fig. 6, so that all files can be associated with the parity.

Fig. 8 shows the flow chart of process 200 for recovering or downloading a file from ^: the clouds, always assuming that the local and the remote stores of the user are to be kept synchronised.

The first step 201 is the user's authentication with the managers of the clouds on which the file is stored. Once the authentication has been performed, metafile 22 (Fig. 3) is downloaded from one cloud, randomly chosen out of the CA clouds (step 202), and the metafile version is compared to the version locally stored (step 203). If the versions coincide, then the process goes on. If the versions' are different (for instance, due to possible previous network problems) , then the metafile is downloaded from another cloud, also randomly chosen (step 204).

Then, a comparison is made between the local store and the index file extracted from the metafile (step 205), in order, to determine whether the locally stored file and the file stored on the clouds are identical. In the affirmative, the program passes to a stand-by condition where access to the clouds for reading the subsequent file is. waited for (step 206), and the process ends.

If the local file and the file stored on the clouds do not correspond, the file fragments are downloaded from the different clouds (step 207), are decrypted and checked for authenticity (step 208), each fragment being stored in a local buffer area. The fragments are then reassembled thereby reconstructing the complete file (step 209), possibly by^' using the parity information if a fragment has been lost. The file is then stored (step 210) in user's local store 12 (Fig. 2). The process for the current file thus ends.

The user also has the possibility of giving up one or more of the clouds on which he/she has stored the files, what obviously compels to redistribute the files among the remaining clouds. Fig. 9 shows flow chart 300 of the¹ redistribution operations in case one cloud is given up. In that process, Y is the overall number of the files to be redistributed and IF is the generic file (0 ≤ IF ^'≤ Y-l).

The first step 301 is executing recovery process 200 depicted in Fig. 8 for all Y files. In this manner, an updated local copy of the files is created which serves as a basis for redistribution. Beginning with the first file (0 <- IF) , step 302, upload process 100 shown in Fig. 4 is then performed on all CA-1 clouds to be kept (step 303) . Once the upload is over, the fragments of the old file are eliminated from all clouds (step 304), the value of IF is incremented (step 305) and steps 303 to 305 are repeated for all subsequent files until exhausting the files, that is as 'long as IF ≤ Y (step 306, output NO) . When IF > Y (step 306, output YES), the process ends.

Another function provided for by the invention is the secure file exchange among users having application 13 (Fig. 2) on their terminals: Fig. 10 shows a user UT (sender) who is to share files of which he/she is the proprietor with a user UR (receiver or consignee). User UT recovers from clouds C(0)...C(x) where the files are stored the links (e.g. in the form of URLs, Universal Resource Locators) to the file fragments stored on each cloud, and uses such links to form a single file (sharing file) F(url) to be sent to receiver UR. The latter, based on the contents of file F(url), can in turn access clouds C(0)...C(x) to download the file fragments and reassemble them by ¹ using the algorithm shown in Fig. 8.

Figs. 11A and 11B show the operations performed by user UT (flow chart 400) and user UR (flow chart 500), respectively. When user UT wishes to perform shari-ng, he/she requests the URLs linking to the fragments of the file(s) to be shared from clouds C(0)...C(x) (step 401) and introduces such URLs into a sharing file F(url) (step 402), which is encrypted (step 403) and sent to receiver UR (step 404) . The latter in turn, upon receiving file F(^'url) (step 501), decrypts it (step 502) and accesses the URLs indicated in file F(url) in order to download the fragments of the file(s) to be shared and to reconstruct the complete file(s) (step 503) .

Fig. 12 shows the logic diagram of unit 13 shown in Fig. 2. Unit 13 includes three sections 13A, 13B, 13C intended to manage file upload to the clouds, file recovery from the clouds and file sharing, respectively.

Section 13A includes:

a module 31 for identifying .the files to be uploaded to the clouds; in the described example of application to the synchronisation of a local store and a remote store on the clouds, that module implements the routine for detecting changes in one or more files in a given working area;

a cloud selecting module 32, which performs the check on the space availability on all clouds to . which a user has access and selects the CA clouds to be used; during file redistribution as^' a consequence of a removal of a cloud, module 32 will command reading of the files from all clouds by section 13B, as schematised by connection 38; '

a file fragmenting module 33, which < receives the files selected by module 31 (or the files downloaded by- section 13B during redistribution) from local store 12 and divides them into NF fragments;

a module 34 for creating the redundancy information, which is activated by module 32 if CA ≥ 2 and is arranged for instance · to compute the file parity in the manner described before; an encrypting and authenticating module 35, which for instance executes algorithm SHA- 256 and procedure HMAC on the file fragments and the parity block;

a metafile creating/updating module 36, which receives the encryption keys and the signature relating to the individual fragments from encrypting and authenticating module 35 and, at the end of the operations concerning each file, sends the metafile created in this manner to a module 37 for uploading the data to the clouds or updates the metafile on all clouds ;

module 37 for uploading the data to the clouds, ^' which receives the information about the identities of the clouds chosen from module 32, the encrypted and authenticated file fragments and redundancy from module 35, and the metafile, if it is created, from module 36, and uploads the file fragments and the redundancy to the different clouds and the metafile to all clouds,

on 13B in turn includes: a module 41- for reading the metafile and the file fragments;

- a module 42 for comparing the metafile downloaded from the clouds to that locally present; the module compares the version of the metafile downloaded by module 41 to the locally present version in order to check the possibility of using the metafile itself and, in case of consistency between the two versions, receives the index file extracted from the metafile from module 41 whereas, if it detects differences between the contents of the remote and the local stores, it commands reading of the file fragments by module 41;

a module 43 for decrypting the file fragments read by module 41;

a . module 44 for reassembling the decrypted fragments, which reconstructs the complete file by possibly exploiting the redundancy information; and

- a module 45 controlling storage of the reconstructed file into local store 12.

Lastly, section 13C includes: three modules active when the user acts as sender user UT (Fig. 10), namely:

a module 51 for requesting and receiving from the clouds the URLs relating to the fragments stored in each cloud;

a module 52 for creating and encrypting sharing file F(url) containing the URLs supplied by module 51;

a module 53 for transmitting file F(url) supplied by module 52 to receiver user UR (Fig. 10);

and

a module 54 for¹ receiving and - decrypting file' F(url), which module is active when the user acts as receiver user UR and is arranged to command execution,^■ by section 13B (as schematised by connection 55), of the process for recovering, the fragments of the files to be shared from the URLs indicated in F(url).

It is clearly apparent that the invention attains the aims set forth. Indeed, the capacity of utilisation of the individual clouds is not determined by the capacity of the smallest cloud, but the user can exploit the whole capacity of all clouds simply by automatically adapting the number and the size of_. the fragments of each file. Moreover, the authentication of the data stored on the individual clouds assures the proprietor that the data have not been altered on the clouds. Further, only the proprietor knows the identities of the clouds on which he/she has stored his/her files, and this provides a further security level against hacking attempts.

It is clear that the above description has been given only by way of non-limiting example and that changes and modifications are possible without departing from the scope of the invention, as defined by the following claims.

Claims

1. A method of storing and/or processing information sets, hereinafter referred to as files, on a plurality of independent clouds (Ca...Cn), the method including:

a) a phase (100) of uploading files generated by users (Ua...Um) to the clouds, including, for each file, the steps of:

dividing the file into a plurality of fragments ( 10 ) ;

possibly associating the file with redundancy information (106);

encrypting the file fragments and the redundancy information, if any (107); and uploading (109 - 116) the file fragments and the redundancy information, if any, to different clouds;

and b) a phase (200) of file download from the clouds, including, for each file, the steps of:

- downloading the file fragments (207) from the clouds (Ca...Cn) to the users (Ua...Um);^{' '}

- decrypting the . fragments (208); and

- reassembling the decrypted fragments (209) to rebuild the file;

characterised in that the upload phase (100) further includes, previously to the division into fragments (104 ) , the steps of :

- checking (102) the storage capacity available on all clouds to which a user has access;

- selecting (103), for storing and/or , processing the file, a cloud set that includes all clouds having storage capacity available or part of such clouds and may contain, for each file, a variable number of clouds;

and in that the ^' division into fragments (104) includes the step' of dynamically and automatically adapting, for each file, the number and the size of the fragments to a current number of clouds in the set .

2. The method according to claim 1 or 2, characterised in that the adapting step is performed in case of both exhaustion of the capacity of one or more clouds in the set and addition of one or more clouds to the set.

3. The method according to claim 1, characterised in that the encrypting step (107) is carried out with different keys for the different file fragments and the redundancy information, if any, and in that the upload phase (100) further^' includes the following steps:

- generating _,(108) an authentication code for the data contained in each fragment;

creating (118) a metafile containing the encryption keys and the authentication codes; uploading (117) the metafile to all clouds in the set;

and the download phase (200) further includes the following steps:

- downloading (202) the metafile from a randomly selected cloud;

comparing (203) a version number of the downloaded metafile with the version number of a corresponding metafile existing at the user; and

in case of inequality, downloading (204) the metafile from a different cloud, it too randomly selected.

4 . The method according to. any preceding claim, characterised in that the upload and download phases (100, 200) are intended to keep a local store (12)^' at a user's premises (Ua...Um) and a remote store (21) on the clouds (Ca...Cn) synchronised together, and in that:

the upload phase (100) is started by the detection of modifications in one or more files in a given working area of the user;

the metafile creating step (118) further includes introducing into the metafile an index file representative of the contents of a file being uploaded to the clouds;

the download phase (200) includes the steps of:

-comparing (205) the contents of the file index with the contents of the local store; and -downloading (207) the file- from the clouds if the comparison detects differences between the contents of the, local and remote stores.

5. The method according to any preceding claim, characterised in that it further includes:

c) a phase (300) of removing one or more clouds from the plurality and consequently redistributing the files between the clouds being maintained, including the steps of:

downloading (301) the files of a user having requested the cloud removal from the clouds to the local store of the user;

uploading again said files (303) to the clouds being maintained;

after the upload of a file (303) to the clouds being maintained, deleting (304) the original version of that file from the clouds;

d) a phase (400, 500) of file sharing between different users, including, for a user (UT) proprietor of the file(s) to be shared, the steps of: requesting (401), from each of the clouds (C (0) ... C (x) ) where the fragments of the file(s) to be shared are stored, links to the locations of the fragments;

introducing (402) said links into a share file (F(url) ) ,-^■

encrypting (403) the share file (F(url));

sending (404) the encrypted share file (F(url)) to users (UR) who are to receive the file(s) to be shared;

and including, for a _/receiving user (UR) , the steps of:

receiving and decrypting (501, 502) the share file (F(url));

downloading (503) the fragments of the file(s) to be shared from the clouds (C ( 0 ) ... C ( x ) ) to which the links point.

6. The method according to any preceding claim, characterised in that it further includes, for a user (Ua...Um) having a plurality of user devices (D1...D5), a phase of mutually synchronising the devices (D1...D5) through an exchange of an access key (AK) consisting of the identities of the clouds used by the user, the exchange taking place in encrypted form.

7. A device to be associated with a user terminal (Ua...Um) for the storage and/or processing of information sets, hereinafter referred to as files, on a plurality of independent clouds (Ca...Cn), the device (13) including:

a first section (13A) for managing file upload to the clouds (Ca...Cn), including:

- means (33) for dividing the files ^■ into a plurality of fragments;

- means (34), for associating the files with possible redundancy information;

- means (35) for encrypting the file fragments and the redundancy information, if any; and

- means (37) for uploading the file fragments and ■ the redundancy information, if any, to different clouds in the plurality;

and

a ^' second section (13B) for managing file download from the clouds (Ca...Cn), including:

- means (41, 43) for downloading from the clouds (Ca...Cn) and decrypting the file fragments; - means (44) for reassembling the fragments and rebuilding the original files;

- means (45) for storing the files having been rebuilt into a local store (12) of the user; and being characterised in that:

the first section (13A) further includes cloud selecting means (32) arranged, for each file to be uploaded, to:

check the storage capacity available on ^" all clouds (Ca...Cn) to which a user^' has access; select a cloud set that includes all clouds having storage capacity available for the file or part of such clouds and may contain a variable number (CA) of clouds; and

communicate the number and the identities of the clouds in the set to the dividing means (33) and the uploading means (37);

and in that the file dividing means (33) are arranged to dynamically and automatically adapt, for each file, the division into fragments -to a current number of clouds in the set.

8. The device according to claim. 7, characterised in that: the encrypting means (35) are arranged to encrypt the file fragments and the redundancy information, if any, with different keys and further include means for generating an authentication code for the data in each fragment; .

- the first section (13A) further includes means

(36) for creating a metafile, which receive from the encrypting means (35) and introduce into the metafile the encryption keys and the authentication codes and which are arranged to crea-te in the metafile an index file representing the contents of a file uploaded to the clouds; and

- the upload means (37) are arranged to upload the metafile to all clouds in the "set;

and in that the second section (13B) further includes:

- metafile download means ^■ (41) arranged to download the metafile from a randomly selected cloud; and

- comparison means (42) arranged to: compare a version number of the downloaded metafile with the version number of a corresponding metafile existing at the user's premises ,(Ua...Um) and, in case of inequality, to cause the metafile to be downloaded from a different cloud, it too randomly selected; and compare the index file with the contents of the local store and to command the file download in case of inequality.

9. The device according to claim 7 or 8, characterised in that it further includes a third section (13C) for managing sharing of one or more files between different users, including,

means (51, 52, 53), active for a user (UT) proprietor of the one or more files to be shared and arranged to:

- request from the clouds links to the locations where the fragments of the one or more file(s) are stored and receive said links from the clouds;

- introduce said links into a share file;

- encrypt the share file; and - send the encrypted share file to users (UR) who are to receive the one or more files;

means (54), active for receiving users (UR) and arranged to receive and decrypt the share file and to command download, by the second section (13B), of the file fragments from the locations pointed to by the link in the share file-.

10. A computer program product to be loaded into the memory of a processing unit (10) and including program code portions for carrying out the method according to any of claims 1 to 6 when the product is executed on the processing unit (10) .