The present invention relates to a method for storing data on a storage entity.

The present invention further relates to a method for performing a proof of retrievability for data stored on a storage entity.

The present invention further relates to a storage entity for storing data.

Even further the present invention relates to non-transitory computer readable medium storing a program causing a computer to execute a method for storing data on a storage entity. Although applicable to any kind of storage or storage entity in general, the present invention will be described with regard to cloud storage.

Cloud services are gaining increasing importance and applicability in a number of application domains, such as storage, computing services, etc. The "cloud" has recently gained several adopters among small and medium enterprises and large businesses that are mainly interested in fast development of new applications while minimizing the costs of both deployment and infrastructure management and maintenance. Cost effectiveness is realized in the cloud through the integration of multi-tenancy solutions and storage efficiency solutions with efficient distributed algorithms that run on commodity hardware to ensure unprecedented levels of scalability and elasticity. The combination of multi-tenancy solutions with storage efficiency techniques, e.g., data deduplication enables drastic cost reductions. For instance, recent studies show that cross-user data deduplication can save storage costs by more than 50% in standard file systems, and by up to 90-95% for back-up applications as shown in the non-patent literature of Frederik Armknecht, Jens- Matthias Bohli, Ghassan Karame, Franck Youssef, Transparent Data Deduplication in the Cloud, In Proceedings of the ACM Conference on Computer and Communications Security (ACM CCS), 2015. Moreover, nearly three quarters of these savings could also be obtained by means of whole file deduplication.

The advent of cloud storage and computation services, however, introduces new threats to data security. Namely, in nearly all conventional cloud services, users lose control over their data and how data is processed or stored. For example, a permanent loss of customers' data in a cloud system due to lightning strikes that affect a local utility grid near a corresponding data center is possible. For example a conventional method which enables users to verify the integrity and availability of their outsourced data include Proofs of Retrievability (POR) is shown in the nonpatent literature of Frederik Armknecht, Jens-Matthias Bohli, Ghassan Karame, Zongren Liu, Christian Reuter, Outsourced Proofs of Retrievability, In Proceedings of the ACM Conference on Computer and Communications Security (ACM CCS), Arizona, USA, 2014. Said conventional method enables providing end-clients with the assurance that the data is retrievable.

Although these conventional methods can be effective in detecting data loss, they completely ignore storage-efficiency requirements, such as multi-tenancy and data deduplication, which are being widely utilized by existing cloud storage providers. Namely, conventional solutions assume a single trusted tenant, i.e. an honest verifier, who pre-processes the files to create tags using secret material before outsourcing them to the cloud, and later regularly performs verifications, e.g., POR on the pre-processed files and tags in order to react as early as possible in case of data loss. However, in practice, given that files are typically deduplicated across tenants, and different tenants do not tend to trust each other, tenants will be reluctant on sharing the secret material used to construct tags in POR/PDP.

On the other hand, solutions where each tenant constructs and stores his own tags in the cloud do not scale well with the number of tenants in the system. In this case, the storage overhead of the tags threatens to cancel out the benefits of data deduplication over popular objects; for instance, the storage overhead required to store the tags of files owned by 20 tenants is almost 200% when compared to the original file size. One of the problems addressed by embodiments of the invention is therefore to provide multi-tenant publicly-verifiable proofs of retrievability. A further problem addressed by embodiments of the present invention is to enable proofs of retrievability in which tenants do not require to mutually trust each other. One of the further problems addressed by embodiments of the present invention is to provide storage efficiency and a secure and easy implementation.

In an embodiment the present invention provides a method for storing data on a storage entity, 'SE',

comprising the steps of

a) Dividing a file to be stored into a number of chunks by a client,

b) Computing a secret key for each chunk of said file,

c) Computing for each chunk a chunk identifier by said client,

d) Checking, by said SE, if one or more of said chunks have already been stored based on said computed chunk identifiers,

e) In case one or more of said chunks have not already been stored:

Encoding the corresponding chunks

Computing chunk tags for said chunks using said computed secret key

Storing said encoded chunks and said chunk tags.

In a further embodiment the present invention provides a method for performing a proof of retrievability for data stored on a storage entity, 'SE', with a method according to one the claims 1 -9, wherein

- a random challenge is computed and provided to said SE, said random challenge comprising a set of one or more coefficients and corresponding indices for said chunks and wherein

- said SE computes a signature with the sum over said set of the product of said coefficients of said challenge and corresponding stored chunk identifiers on said SE, and wherein

- said SE computes a file part with the sum over said set of the product of said coefficients of said challenge and corresponding stored chunks, and wherein said client verifies retrievability of said data by checking whether the signature computed by said SE can be matched with the computed file part and local information of said client to be used for generation of a chunk identifier

In a further embodiment the present invention provides a storage entity for storing data according to the method of claim 1 , being adapted to store a chunk together with a chunk identifier.

In an even further embodiment the present invention provides a non-transitory computer readable medium storing a program causing a computer to execute a method for storing data on a storage entity, 'SE',

said method comprising the steps of

a) Dividing a file to be stored into a number of chunks by a client,

b) Computing a secret key for each chunk of said file,

c) Computing for each chunk a chunk identifier by said client,

d) Checking, by said SE, if one or more of said chunks have already been stored based on said computed chunk identifiers,

e) In case one or more of said chunks have not already been stored:

Encoding the corresponding chunks

Computing chunk tags for said chunks using said computed secret key

Storing said encoded chunks and said chunk tags

The terms "storage entity" and "client" refer in particular in the claims, preferably in the description each to a device or devices adapted to perform computing like a personal computer, a tablet, a mobile phone, a server, a router, a switch or the like and comprise one or more processors having one or more cores and may be connectable to a memory for storing an application which is adapted to perform corresponding steps of one or more of the embodiments of the present invention. Any application may be software based and/or hardware based installed in the memory on which the processor(s) can work on. The devices or entities may be adapted in such a way that the corresponding steps to be computed are performed in an optimized way. For instance different steps may be performed in parallel with a single processor on different of its cores. Further the devices or entities may be identical forming a single computing device. The devices or devices may also be instantiated as a virtual device running on a physical computing resource. Different devices may therefore be executed on said physical computing resource.

The term "computer readable medium" may refer to any kind of medium, which can be used together with a computation device or computer and on which information can be stored. Said information may be any kind of data which can be read into a memory of a computer. For example said information may include program code for executing with said computer. Examples of a computer readable medium are tapes, CD-ROMs, DVD-ROMs, DVD- RAM s, DVD-RWs, BluRay, DAT, MiniDisk, solid state disks SSD, floppy disks, SD-cards, CF-cards, memory-sticks, USB-sticks, EPROM. EEPROM or the like.

At least one embodiment of the present invention may have at least one of the following advantages

- deduplication is enabled not only of the files but also of the proof-of- retrievability tags across mutually untrusted tenants,

different tenants do not require to share any secret material with each other, enhanced security since resistance against malicious proxy servers and cloud providers is enabled,

- storage efficiency.

Further features, advantages and further embodiments are described or may become apparent in the following: Said secret key may be computed based on an oblivious key generation procedure with a trusted entity. An oblivious key generation may involve a basic secret key held by the trusted entity and ensures that a trusted entity does not learn any information for example about the file to be stored for which the key are generated. Thus security is enhanced.

Said chunk identifiers may be computed based on the contents of said chunk and said secret key. This enables for example file identifiers being dependent on the contents of each chunk. Said file is divided into said number of chunks by using Rabin fingerprinting. This allows in an easy and reliable way to provide content-dependent chunk or file identifiers. The client may generate at least two different secret keys using different secure key generation functions, wherein one of the secret keys is used for encrypting the file and one of the other secret keys is used for the generation of said chunk tags. This enhances the security since different keys can be used for encrypting the file and tagging the file respectively the chunks.

The corresponding chunks in step e) may be encoded using an information dispersal algorithm like erasure coding. Erasure coding ensures that extractability is provided such that a proof of retrievability can be easily and reliably performed. The chunk tags may be signatures, a signature for a chunk being computed based on a signature generation function with input of a random number, said secret key of step c) and the contents of the chunk. This enables to generate proof of retrievability with the tags in an easy and reliable way. Said signature generation function may be computed as a linear combination of a pseudorandom-function and a product of said random number and the contents of said chunk, wherein said pseudorandom function being secret key-dependent and a random number-dependent. This allows in a fast and reliable way to provide content dependent chunks for a later verification during a proof of retrievability.

Said secret key may be computed locally using a local hardware token on said client, which may be provided by said SE. This enhances the security since this enables full protection of these keys against leakage or compromise. For example this can be used in TPMs or smartcards that are used by cloud vendors to pre- provision secret keys in the clients. The server aided key generation protocol is then emulated locally. Communication between clients and an outside trusted entity is then not done via an internet connection or the like but locally since the trusted entity is now emulated by the local hardware anchor present within the client device. There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the patent claims subordinate to the independent claims on the one hand and to the following explanation of further embodiments of the invention by way of example, illustrated by the figure on the other hand. In connection with the explanation of the further embodiments of the invention by the aid of the figure, generally further embodiments and further developments of the teaching will be explained.

In the drawings

Fig. 1 shows schematically part of steps of a method according to an embodiment of the present invention;

Fig. 2 shows schematically part of steps of a method according to a further embodiment of the present invention;

Fig. 3 shows schematically part of steps of a method according to a further embodiment of the present invention;

Fig. 4 shows schematically part of a system according to a further embodiment of the present invention;

Fig. 5 shows schematically part of steps of a method according to a further embodiment of the present invention;

Fig. 6 shows schematically part of steps of a method according to a further embodiment of the present invention and

Fig. 7 shows schematically a method according to a further embodiment of the present invention Fig. 1 shows schematically part of steps of a method according to an embodiment of the present invention.

In Fig. 1 information flow between a proof of retrievability generation service and a user is shown. The proof of retrievability, 'POR', generation service is connected by a network to the user. The POR-generation service provides a POR key for the user. The user uses the POR key for computing for each chunk a chunk tag or chunk identifier. Fig. 2 schematically shows part of steps of a method according to a further embodiment of the present invention.

In Fig. 2 the user is provided with a proof of retrievability-dongle as a trusted entity which allows emulating locally a server aided key generation similar to Fig. 1. The communication between the POR-dongle and the user is for example performed via a wired connection like USB. The POR-dongle allows then to emulate the POR generation service similar to Fig. 1 to generate a POR key which is then in turn used by the user to compute chunk tags or chunk identifiers. In more detail: In the following a number of clients or users U1 , U2, ... is assumed that are interested in storing their files at a storage provider S. Said storage provide S exposes to its clients e.g. a standard interface comprising some simple operations, such as storing a file, retrieving a file, deleting a file, generating a URL for sending HTTP commands for storage/retrieval, etc.

Further a proxy or gateway is assumed to be present which can be queried by the clients U 1 , U2, ... to assist them in deriving in an oblivious way a strong encryption key for content to be deduplicated. The clients U1 , U2, ... are interested in obtaining a cryptographic proof that their files are stored in the cloud S in their entirety. For this purpose, the clients U1 , U2, ... and the cloud S frequently execute a challenge-response protocol to verify the integrity and availability of the file. Further the clients U1 , U2, ... and the proxy share per-user keys and credentials (e.g., client certificates). In particular, all communication between a client U1 , U2, ... and the proxy is authenticated and, may also be, encrypted. Even further a secure encryption algorithm Enc and a cryptographic hash function H are provided.

The proxy is assumed to be honest but curious and that the cloud provider S is assumed to be malicious. Different tenants are assumed to not trust each other (and will not share a pair-wise key with each other). The proxy is announced to not collude with the cloud provider S at all times. This can be effectively realized if the proxy and the cloud provider S originate from different administrative domains.

In the embodiment, the key generation process is based on chunks and the principle to establish another secret which is used to bootstrap the POR tags is used.

In this case, if another tenant is trying to store the same file, the tenant will also be able to construct the same POR tags. In detail K denotes the key output by the client U1 , U2, ... after executing the oblivious server-aided generation protocol with the proxy. Given K, the client U1 , U2, ... generates two new keys using two different secure key derivation functions KDFi and KDF ₂ . Namely, let Ki = KDFi (K), and K ₂ = KDF ₂ (K).

The client U1 , U2, ... then computes for each chunk of the file a chunk identifier FID (e.g., based on K-i) and sends it to the cloud provider S. Here, two cases emerge: i) The FID has not been stored by another tenant

ii) The FID has been stored by another tenant ln case of I and since it is assumed that the cloud provider S keeps track of all file identifiers for the stored file, the cloud provider S can check whether the same file has been previously stored by another tenant. In case FID does not exist, the cloud S asks the client U1 , U2, ... to upload the file.

In this case, the client U1 , U2, ... encrypts the file F using Ki and computes a ciphertext C= Enc (K-i, F). The client U1 , U2, ... then applies an information dispersal algorithm on said ciphertext C and computes the POR tags using secret key K2 according to the underlying POR scheme. In Figure 7 a concrete instantiation is shown using the Shakham Waters privately-verifiable POR scheme. The tags of the files are here announced to be computed based on content. This can be performed by utilizing the Rabin fingerprinting algorithm, or by leveraging any similar content-based algorithm. In case of ii) the client U1 , U2, ... directly conducts a POR with the storage provider S. The POR can be verified using the key K2 generated by the client U1 , U2, ... as shown in Figure 7. This method ensures that the cloud S indeed has the files and that the tags have been computed correctly by the previous tenants. Fig. 3 schematically shows part of steps of a method according to a further embodiment of the present invention.

In Fig. 3 on the left side a file is shown which is then divided into chunks. A proof of retrievability dongle acting as gateway or proxy provides the key for encrypting the chunks and tagging the chunks by computing corresponding tags for the chunks. The chunks together with the tags are then provided to the server S, indicated by "upload".

Fig. 4 schematically shows part of a system according to a further embodiment of the present invention.

In Fig. 4 an example of a proof of retrievability according to an embodiment of the present invention is shown using deduplicated content-chunked blocks pertaining to 2 users. In Fig. 4, two users, User 1 , User 2 each have a dongle for corresponding key computation. User 1 performs the steps of Fig. 3, i.e. dividing the file to be uploaded into chunks and encrypting the chunks as well as computing the corresponding tags for the chunks. Said User 1 the n uploads this information into the cloud S.

If User 2 wants to store chunks of a file he computes corresponding chunks identifiers and uploads them to the cloud S. The cloud S then checks whether a corresponding chunk identifier match to corresponding already stored chunks. Here in Fig. 4 all the chunks have already been stored. Thus User 2 only updates the corresponding tags in the cloud.

Fig. 4 and Fig. 3 enable different clients U1 , U2, ... to agree on keys without the need for clients U1 , U2, ... to trust each other. Here hardware support is leveraged to pre-provision keys in such a way that these keys can never leave the client devices. This ensures full protection of these keys against leakage or compromise. For instance TPMs, smart cards and other methods enable cloud vendors to pre- provision secret keys in their clients, thus emulating a local assisting sever-aided key generation. In this case, the protocol unfolds exactly similarly to the protocol Fig. 7. However, communication between clients U1 , U2, ... and the proxy is not done via WAN, but locally, since the proxy is now emulated by the local hardware anchor present within the client device. Fig. 5 schematically shows part of steps of a method according to a further embodiment of the present invention.

In Fig. 5 a method for storing data is shown comprising the steps of 1) Chunking the file contents in variable sized chunks to achieve efficient storage savings.

2) Executing an oblivious server-aided key generation protocol to establish a

secret key used to create the POR tags and to verify POR

3) Computing a chunk ID and for each chunk and sending it to the cloud provider. 4) If the chunk ID is not stored, encrypt the chunk using secret key and compute POR tags and store chunk and tags at the cloud.

5) If the chunk ID is stored, conduct immediately a POR with the cloud provider and verify the POR response using the secret key output by the oblivious server-aided key generation process.

Fig. 6 schematically shows part of steps of a method according to a further embodiment of the present invention. In Fig. 6 a method for storing data on a storage entity, 'SE',

comprising the steps of

a) Dividing a file to be stored into a number of chunks by a client,

b) Computing a secret key for each chunk of said file

c) Computing for each chunk a chunk identifier by said client

d) Checking, by said SE, if one or more of said chunks have already been stored based on said computed chunk identifiers

e) In case one or more of said chunks have not already been stored:

Encoding the corresponding chunks

Computing chunk tags for said chunks using said computed secret key

Storing said encoded chunks and said chunk tags

Fig. 7 schematically shows a method according to a further embodiment of the present invention.

In Fig. 7 a key generation for obtaining a key as output after executing an oblivious server aided key generation a protocol is shown. This key is then used of the basis for file encryption and a proof of retrievability setup. To perform the proof of retrievability a challenge-response protocol, POR challenge and POR response is used. The POR response is then verified executing a POR verification procedure.

In detail: The proxy chooses two groups Γ1 and Γ2 with order p, and a computable bilinear map e: Π ^χ Γ2→ Γτ . Additionally, the proxy chooses n private keys x-i, x _n <≡ Zp, and their corresponding public keys y[ = g ¹ £ _χ and y = g £ Γ ₂ . Let H ^* : {0, 1 } ^* → Γι be a cryptographic hash function which maps bitstrings of arbitrary length to group elements in Π . Prior to storing a file or a chunk f , the client computes h <- H ^* (f ), blinds it by multiplying it with g[ , given a randomly chosen r e Zp, and sends the blinded hash h to the gateway. The latter derives the signature on the received message and sends the result back to the client, who computes the unblinded signature s and verifies that:

e(s, g ₂ ) = e(h ^x g[ ^Xi g ^~rXi , g ₂ ) = e(h, y ₂ ^l )

If the verification is positive then the hash of the unblended signature gives the key k output after the execution of the oblivious server aided generation protocol. Given said key k the client generates then a new key using a secure deviation function KDFi and encrypts the file F with said generated key Ki. The client then further applies on the ciphertext C, i.e. the encrypted file F an erasure code and computes then the POR tags according to the following: The ciphertext being erasure coded is split into a number n of content defined blocks m-i, m _n ε Z _p . Then a random number a _t E _R TL _V is chosen and a key k for a pseudorandom function f. The POR tags are then computed for each chunk according to

a, = fk (i) +am, ε Zp.

The corresponding content defined blocks m, and the corresponding tags oi are then transmitted for storage to the cloud S.

To perform a proof of retrievability as mentioned before a proof of retrievability challenge-response is used: To create or generate a POR challenge a random challenge set / _≡ _R [l, n] of size I is chosen together with a random coefficients v _£ £ _R Έ _ρ and the corresponding set Q:={(i, ν )}\ e \ is sent to the cloud S.

The cloud S then computes a sum of these random coefficients with the provided POR tags to compute the overall file identifier: σ <-∑^ _tVi -) _≡ Q v _t a _t . Further the same is performed for the corresponding content-defined blocks over the set Q:

μ <-∑(£, _Vi) eQ vi rrii These computed values for the signature σ and the content-defined blocks μ is then transmitted back to the client U1 , U2 for verification. The client U1 , U2 then verifies if the computed signature equals

?

σ ₌ αμ +∑ _iiiV . _)eQ vj^i) .

If verification is successful then the data is proved to be retrievable.

In summary embodiments of the present invention enable a management and protection of the keys compared with convergent encryption. Further embodiments of the present invention enable to first split a given file in the chunks for example in a content dependent way which enables deduplication. These chunks are useful performing a proof of retrievability significantly enhancing conventional proof of retrievability methods. Further embodiments of the present invention enable to tie the savings of deduplication with proofs of retrievability. For each chunk key is obtained deterministically according to embodiments of the present invention and the proof of retrievability is executed using that key.

Embodiments of the present invention may have at least one of the following advantages:

- supporting deduplication of files and their corresponding proof of retrievability tags across users

ensuring enhanced storage efficiency

pairwise keys do not have to be shared, different tenants do not need to synchronize with each other

- management of keys

protection of the keys

high security, in particular against malicious proxy servers and malicious cloud providers Many modifications and other embodiments of the invention set forth herein will come to mind to the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.