Abstract The geographic location of cloud data storagecentres is an important issue for many organisations and indi-viduals due to various regulations that require data and oper-ations to reside in specific geographic locations. Thus, cloudusers may want to be sure that their stored data have not beenrelocated into unknown geographic regions that may compro-mise the security of their stored data. Albeshri et al. (2012)combined proof of storage (POS) protocols with distance-bounding protocols to address this problem. However, theirscheme involves unnecessary delay when utilising typicalPOS schemes due to computational overhead at the serverside. The aim of this paper is to improve the basic GeoProofprotocol by reducing the computation overhead at the serverside. We show how this can maintain the same level of secu-rity while achieving more accurate geographic assurance.
Cloud computing delivers a huge range of virtual and dynam-ically scalable resources, including computational power andstorage, to users of Internet technologies. These servicescould help private and government organisations to outsource
A. Albeshri (B) · C. Boyd · J. G. NietoQueensland University of Technology, Brisbane, Australiae-mail: [email protected]
A. AlbeshriFaculty of Computing and IT, King Abdulaziz University,Jeddah, Saudi Arabia
C. BoydNorwegian University of Science and Technology,Trondheim, Norway
their data storage to cloud providers. However, a major chal-lenge to cloud computing is how to secure the data of theuser against a malicious server.
Geographic assurance involves ensuring that the customerdata have not been stored in a location contravening locationrequirements specified in the service level agreement (SLA).A critical obstacle that may face any organisation thinkingto migrate to the cloud computing is where will their dataphysically reside? This is because there may be certain leg-islative requirements on data and operations to remain incertain geographic locations. In addition, the location of thedata storage has a significant effect on its confidentiality andprivacy. This is due to the different laws and regulations thatvary between countries around the globe. Note that certainregulations and laws require data and operations to reside inspecific geographic locations.
Many of the cloud providers claim that they will locatethe data in a specific region and will not change it. However,there is no guarantee that the cloud provider may not changethe location intentionally (seeking cheaper infrastructures) oraccidentally. In fact, many of todays cloud providers claimin the SLA that the data will be stored and maintained in cer-tain geographic locations. However, cloud customers need totrust the cloud provider and the only guarantee that the cloudprovider will meet its commitment is through the contractitself. Also, cloud service providers may violate the SLA byintentionally or accidentally relocating the stored data intoremote data centres that may be located outside the specifiedgeographic boundaries seeking cheaper IT costs. For this rea-son, cloud customers may need to verify that their data arelocated in the same geographic location specified at contracttime and make sure that the cloud service provider continuesto meet their geographic location obligations.
Albeshri et al. [1] propose a new protocol (GeoProof)that is designed to provide a geographic assurance for data
123
A. Albeshri et al.
owners that their data remain in the same physical locationspecified in the SLA. GeoProof combines the proof of storageprotocol (POS) with the distance-bounding protocol. A POSprotocol is an interactive cryptographic protocol that allowsthe client to verify the data without needing to download theoriginal data; a distance-bounding protocol is an authentica-tion protocol between a verifier and a prover, in which theverifier can verify the claimed identity and physical prox-imity of the prover. The GeoProof protocol combines thePOS scheme with a timing-based distance-bounding proto-col. Specifically, they employ the MAC-based variant of theprotocol of Juels and Kaliski [6] and time the multi-roundchallenge-response phase of the protocol to ensure that thedata are close by to the prover. This allows the client to checkwhere their stored data are located, without relying on theword of the cloud provider.
The basic GeoProof protocol [1] requires the same com-putational overhead at the cloud side as is used in the underly-ing POS protocol in order to compute the required proof andsend it back to the verifier. This computational overhead mayincur a significant time delay that will affect the accuracy ofthe geographic location. Even a relatively small time delayis significant; using measurements of Katz-Bassett et al. [8],Albeshri et al. [1] estimate that data could travel up to 200 kmin 3 ms, greatly degrading the accuracy of location estimates.
The aim of this paper is to enhance the basic GeoProof pro-tocol [1] by reducing and delaying server side computation.The main idea is to avoid or delay all significant computa-tional parts of the proof at the provider side. This will producea saving in time for the server response, which will increasethe location accuracy of the stored data. The timing phasein the enhanced GeoProof will minimise any possible timedelay that may be caused by the computation overhead on theserver side. By applying our improvement to concrete pro-tocols using parameters suggested by the original authors,we show that we can improve the accuracy of location ofdata by hundreds or even thousands of kilometres dependingon the complexity of the POS scheme in use. We also showthat our improvement does not undermine the security of theunderlying POS protocol.
The rest of this paper is organised as follows. The secondsection elucidates the background and motivation for thiswork. The third section gives the details of the enhancedGeoProof and shows how it can be applied to sample concreteprotocols. This section also provides security and efficiencyanalysis in order to validate the usefulness of the proposal.Finally, the fourth section draws conclusions.
2 Background and motivation
Recently, there has been some interest in the issue of geo-graphic location assurance in the cloud. For instance, Peter-son et al. [9] presented a position paper that talks about how
to combine a POS protocol with geolocation, but withoutgiving any details. Also, Benson et al. [3] discuss how toobtain assurance that a cloud storage provider replicates thedata in diverse geolocations. Although their work is similarto GeoProof [1] in the sense of measuring the responses ofthe POS schemes, neither of these papers gives any detailsregarding the usage of distance-bounding protocols or how toappropriately and securely integrate them into a POS scheme.
2.1 GeoProof
The main idea of the basic GeoProof protocol [1] is to com-bine the POS scheme with a timing-based distance-boundingprotocol. POS schemes mainly follow the same basic struc-ture of a multi-round challenge-response protocol. In Geo-Proof, each protocol round is timed to ensure that the dataare close by to the prover. Also, in order to reduce the delayresulted from the network traffic, the verifier will be locatedinside the local network of the cloud provider [1]. However,the basic GeoProof protocol may involve significant timedelay at the server side due to the computational overhead inthe underlying POS scheme. This time is needed to computeand generate the proof and send it back in each challenge-response round. Since distance-bounding protocols are verysensitive to timing differences, this delay can have a signifi-cant effect on the accuracy of the data location estimate.
As an example, Fig. 1 shows the complexity overhead ina typical application of GeoProof. This example is a simpli-fied version of the dynamic proof of retrievability schemeof Wang et al. [11]. In this scheme, a data owner has a fileF consisting of n message blocks {m1, m2, . . . , mn} storedon the cloud server. At the setup time, the owner sends Fto the server together with a set of signatures σi for eachmessage block mi (other variables are omitted). When the
Fig. 1 Example use of GeoProof
123
Enhanced GeoProof
verifier (which could be the data owner or a trusted thirdparty) wishes to check that F is still held at the cloud server’sstated location, it sends a challenge consisting of a set ofindex/random value pairs where the indices are from someset Q ⊂ {1, . . . , n}. The size of Q depends on the level ofassurance, which the verifier wishes to achieve. The servershould then respond with two values μ = ∑n
i=1 νi mi andσ = ∏n
i=1 νσii . This is a non-trivial computation, which will
delay the response from the server by a significant time.In addition to the POS, the GeoProof protocol measures
the time taken for the server to respond and uses this to boundthe distance that the server is away from its claimed location.Wang et al. [11] gave performance estimates for their pro-tocol, which indicate that around 6.52 ms is the time thata server may reasonably take to compute the response. Asnoted above, data can travel more than 400 km in this time,resulting in an error in the distance-bounding protocol of thesame amount.
What is new in this work is to optimise the GeoProof proto-col [1] by reducing and delaying the server side computationmotivated by the observation that the server side computa-tion is likely to provide a delay, which is significant to theaccuracy of the geographic location measurement. Notingthat the different proofs of storage protocols tend to havethe same overall structure, we suggest a generic method ofoptimising such protocols using two techniques. In terms ofthe example in Fig. 1, we firstly require the server to sendthe small set of blocks indexed in Q instead of the hashes.We then move calculation of μ to the verifier side since theverifier now has all necessary data to compute it. Secondly,we delay the computation of μ until after the timing phaseis complete. The cost of sending the message blocks backinstead of hashes is an increase in the data sent. However,our technique minimises the computation on the server sideduring the timing phase, which is simply the time requiredto look up the blocks requested in the challenge.
2.2 Proof of storage schemes (POS)
Proof of storage protocols is a key component in secure cloudstorage proposals in the literature. A POS is an interactive
cryptographic protocol that is executed between clients andstorage providers in order to prove to the clients that theirdata have not been deleted or modified by the providers [7].The POS protocol allows the client to verify the data withoutthe need of having the data in the client side. Since the datamay be of huge size, this is an essential property. The POSprotocol will be executed every time a client wants to verifythe integrity of the stored data. A key efficiency requirementof POS protocols is that the size of the information exchangedbetween client and server is small and may even be indepen-dent of the size of stored data [4].
Proof of storage schemes are sometimes differentiatedfrom schemes for proof of retrievability (POR). The pur-pose of POR and POS schemes is essentially the same—thedifference between them is that in a POR scheme, the datacan be recovered from the protocol itself while this may notbe the case for a POS. Another possible difference betweenschemes is that they may be static or dynamic. Earlier POSschemes were static, which means that they did not allowdata to be changed without repeating the setup phase. Later,some dynamic schemes were developed, which allow data tobe updated while the scheme is running. Our enhancementsseem to be equally applicable to all these variants of POSschemes.
In general, most POS schemes use randomly selectedblocks to challenge the prover. This provides assurance thatwith a high probability, the data file is stored correctly, and ifthe prover modifies any portion of the data, the modificationwill be detected with high probability. In addition, if the dam-age is small, it can be reversed using additional techniquessuch as error-correcting codes.
Table 1 shows the structure of the exchanged challengeand response messages of some of the prominent POSschemes. They are from recent POR schemes, and mostimportantly, we choose the POR schemes in which the datablocks (mi ) are input to compute the proof generated atthe cloud provider side. Thus, we need to look for eachPOS scheme and see what details they exchange, what isthe size of data blocks exchanged, and what computation isrequired on both sides. In fact, most recent schemes do notexchange the actual data blocks such as proofs of retrievabil-
Table 1 Overview of existing POS schemes
POS scheme chal message Proof transcript
Proof of retrievability (POR) [6] Indices for sentinels/MAC Sentinels/MAC
Compact POR [10] {(i, νi )}i∈I ; ν is random value and i is block index σ = ∑νi · σi
μ = ∑νi · mi
Dynamic POR with public verifiability [11] {(i, νi )}i∈I ; ν is random value and i is block index μ, σ, sigsk(H(R)),
{H(mi ),�i }i∈I
Provable data possession (PDP) [2] c, k1, k2, gs T = T a1i1,mi1
ρ = H(ga1mi1+···+acmics modN )
123
A. Albeshri et al.
ity (POR) scheme by Juels and Kaliski [6]. They use sen-tinels or MACs (message authentication codes) to generatethe proof.
It is important for our technique that the POS allows theverifier to specify a subset of the messages (data blocks)which the server (provider) can send back. Also, the servershould send either MACs or linear combination of the MACsor any sufficient information that allow the verifier to ver-ify that the server actually sent the genuine messages (seeSect. 3.1.2).
In summary, we are able to apply our enhancement tech-niques as long as the format of the POS satisfies the followingtwo conditions:
1. the verifier specifies a subset of messages (data blocks) tobe checked as a challenge;
2. the verifier can use the proof transcript (retrieved mes-sages) to verify the authenticity of the messages.
3 Enhanced GeoProof
In this section, we first provide a generic construction of ourenhanced version of GeoProof, which can be applied to allprominent protocol which we have examined. We then lookat a concrete instantiation based on the compact POR proofof Shacham and Waters [10].
3.1 Generic enhanced GeoProof
In general, the POS schemes should allow the verifier tospecify any random subset of blocks and the server (provider)sends back the required blocks with their MACs or a linearcombination of the MACs. Signatures can also be used by theverifier to verify the authenticity of the received data blocks.
3.1.1 Structure of enhanced GeoProof
The main idea of the enhanced GeoProof is to add a tim-ing phase before running the POS protocol. The genericenhanced GeoProof consists of the following phases (seeFig. 2):Setup phase In this phase, the verifier divides the data file Finto blocks m1, . . . , mn . Also, the verifier computes a MACor signature σi on each data block. The client sends data filemi and authenticators σi for 1 ≤ i ≤ n to the cloud storage.Timing phase This phase involves running a distance-bounding protocol and challenging the cloud provider with aset of random selected blocks indexed by a set Q. The verifierthen starts the challenge-response protocol by sending blockindex i to the prover and starts the clock �ti . The proverneeds to respond by sending back the requested data block
Fig. 2 Generic enhanced GeoProof
mi and upon the receiving of the block, the verifier stops theclock.
This stage could be run as a multi-round phase for eachindex or simply run once by sending the set of indices ofrandom selected blocks. For each challenge response, theverifier calculates how long it takes to retrieve the requesteddata block. The verifier cannot verify the retrieved blocksmi at this time because the original blocks are not kept in theverifier side. However, the verifier can verify retrieved blocksmi using information from the next POS phase. This timingphase assures with high probability that most of blocks arethere. In addition, this phase does not involve any computa-tion overhead at the server side.POS phase The main idea of this phase is to run the nor-mal POS protocol that typically involves significant server(cloud) side computations. The number of blocks to bechecked in this phase is equal to or larger than the number ofblocks in the timing phase. In this phase, the verifier sends achallenge message to the cloud server. The cloud server willuse the challenge message in order to compute the proof andresponds by sending it back to the verifier. Now, the verifier isable to verify the integrity of the retrieved data blocks using
123
Enhanced GeoProof
the retrieved proof. The POS phase does not involve any timecalculations. This phase ensures that all the blocks are there.
3.1.2 Security analysis
The POS scheme allows the verifier to check that a randomsubset of blocks is stored at the cloud side. In the timingphase, the verifier gets assurance that the data block mi valuesare nearby for the time being. Then, the verifier wants to beassured of the following.
1. The blocks mi are genuine blocks. So, from the distance-bounding point of view, the verifier challenges a subsetof the blocks. The next step is to verify that the retrievedblocks are the genuine blocks. In fact, we want from theoriginal POS protocol that the subset of the messagesand the transcript of the proof can be used to verify themessages. Thus, the security of the timing phase requiresthe linkage between the messages and the proof. Theverifier needs to be able to check that linkage. To seethat, this still holds; note that in our enhanced GeoProof,we simply change the order of phases and we still have avalid proof transcript so we can validate the authenticityof the retrieved messages.
2. Sending the blocks mi in advance does not compromisethe POS scheme. For the security of the POS, we wantto make sure that the POS scheme still holds even whenthese messages (blocks) are sent to the verifier ahead oftime and even when part of the proof is computed at theverifier side. As stated above, these retrieved blocks mi
are valid and we rely on whatever coding techniques (e.g.,error correction code) have been used in the original POSscheme.
In general, to maintain the security level as the originalscheme, we use the security parameters recommended by thevarious original POS schemes. Also, the geographic assur-ance is maintained by the timing phase in the proposedscheme.
3.1.3 Performance analysis
In the enhanced GeoProof, there is a saving on the server sideresulting from not computing part of the proof at the serverside. In fact, the timing phase, which is mainly responsi-ble for location assurance, does not involve any computationoverhead at the cloud provider side. This is because in thetiming phase, we request some of the data blocks and calcu-late the time needed to look them up and communicate them.The proof computation is divided into two parts, the first onewill be done at the verifier side and the other part will becalculated at the provider side but outside the timing phase.Thus, this saving will increase the location accuracy from
the server omitting the proof in the timing phase. The timingphase in the enhanced GeoProof will minimise any possibletime delay that may be caused by the computation overheadon the server side. As a trade-off, moving the computation ofpart of the proof into the verifier side will introduce an addi-tional computation overhead at the verifier side. This needsto be quantified for each POS scheme used.
In the public verifiable compact POR and also the dynamicPOR (see Table 1), most of the server side computation over-head results from computing σ (σ = ∏
i=1 σνii ). Computa-
tion of σ involves a number multiplications or exponentia-tions. However, it can be expected that in the future, the serveroverhead delay may be reduced as we get better processorsand more efficient technologies.
3.2 Concrete enhanced GeoProof
The previous generic schemes are a conceptual framework,which can be applied on any POS scheme; now, we will lookin more detail at a concrete protocol in order to get a betterunderstanding of the possible overheads. We have verifiedthat our technique applies also to any of the concrete pro-tocols listed in Table 1. In fact, some POS schemes do notexchange the actual data blocks such as proofs of retrievabil-ity (POR) scheme by Juels and Kaliski [6]. They use sen-tinels or MACs (message authentication codes) to generatethe proof, and so our generic technique does not apply.
Shacham and Waters [10] introduced compact proofs ofretrievability. There are two variants of their scheme, onewith private verifiability and the other with public verifia-bility. In both types, the data owner encodes the file usingerasure encoding. As mentioned in Sect. 3.1.2, this enablesthe verifier to be sure that the stored file still safely stored.Shacham and Waters [10] prove that a fraction of the blocksof the erasure-coded file suffice for reconstructing the origi-nal file using the coding techniques.
We look in detail at the Shacham and Waters scheme withprivate verifiability. The scheme with public verifiability canalso be enhanced in a similar way. The encoded file is brokeninto n blocks m1, . . . , mn . Then, each block mi is authenti-cated as follows: σi = MACk(i)+αmi where α is a randomvalue, k is a key known only to the verifier, and MAC is anunforgeable message authentication code. The data blocks{mi } and authenticators {σi } are sent to the server.
The compact POR protocol is as follows. The verifierspecifies a random set of indices Q, and for each index,i ∈ Q associates it with a random value νi . The verifier sends{(i, νi )i∈Q} as a challenge message to the prover. The proverthen calculates the response as follows: σ = ∑n
i=1 νiσi andμ = ∑n
i=1 νi mi and then sends the pair (μ, σ ) to the verifier.
The verifier checks that σ?= α · μ + ∑
νi · M ACk(i).
123
A. Albeshri et al.
Fig. 3 Enhanced GeoProof with compact POR
The security of the compact POR scheme [10] relies onthe secrecy of α. The verification process will assure thatthe prover can only respond by sending the correct messagesas long as the MAC/signature scheme used for file tags isunforgeable and the symmetric encryption scheme is seman-tically secure.
Figure 3 shows the enhanced GeoProof that combines thecompact POR with the timing phase in the distance-boundingprotocol. The structure of this scheme consists of the follow-ing phases.Setup phase In this phase, the verifier (V) divides the datafile F into blocks m1, . . . , mn . Also, V authenticates eachdata block by choosing a random element α and calculatesσi = M ACk(i) + αmi . The client sends data file {mi }1≤i≤n
and authenticators {σi }1≤i≤n into the cloud storage.Timing phase In this phase, V chooses a random set of indicesQ and for each index associates it with a random value νi
(Q = {(i, νi )}); | νi |= 80 bits. V then starts the challenge-response protocol by sending block index i to the proverand starts the clock �ti . The prover in the other side needsto respond by sending back the requested data block mi and
upon the receiving of the block, V stops the clock. As a resultof this phase, V will be able to compute μ = ∑
νi ·mi ; i ∈ Qlocally.POS phase Now, V sends {νi }i∈Q to the cloud. The cloudprovider will compute σ = ∑
νiσi ; i ∈ Q and responds bysending back σ to V.Verification The verifier will verify the retrieved informationas follows.
σ?= α · μ +
∑νi · M ACk(i)
= α∑
νi · mi +∑
νi · M ACk(i)
=∑
νi (α · mi + M ACk(i))
=∑
νiσi = σ
Performance analysis The compact POS scheme involves acomputation overhead at the server side resulting from com-puting σ and μ. However, in the enhanced GeoProof, com-puting the first part of the proof (μ) has been moved to theverifier side. In addition, none of the proof is computed inthe timing phase. Thus, the timing phase, which is mainlyresponsible for location assurance, does not involve any com-putation overhead at the cloud provider side. This results inreducing the time delay at the server side increasing the loca-tion accuracy.
Considering the parameter selection as in the original POSscheme [10], let n be the number of blocks in the file. Assumethat n � λ, where λ is the security parameter and typi-cally λ = 80. A conservative choice is to use a 1/2-rateerasure code and l = λ, where l is the number of indices inthe request message Q. Each file block mi is accompaniedby an authenticator σi of an equal length. The total storageoverhead is twice the file size plus the overhead from theerasure coding. Also, the response of the POR protocol is2× | σi |.
Using the compact POR scheme in GeoProof involvesextra data to be exchanged, which could result in someinefficiency for the whole system. In the timing phase, theresponses from the prover are the actual data blocks. In fact,the communication cost increases linearly with the blocksize [11]. However, with the parameters suggested above,the communications’ requirements are modest. For example,Shacham and Waters suggest that the size of Q can be just 12and the message block consist of 160-bit strings. What weare really concerned about is how to minimise the delay inthe timing phase so the modest increase in communication isa reasonable cost to achieve this ( e.g., by locating the verifieror a device that can run the timing challenge response insidethe local network of the cloud provider and very close to thestorage devices).
123
Enhanced GeoProof
4 Discussion and conclusion
Security is a major challenge for cloud computing providers.Geographic assurance is an example of a significant securityissue in the cloud environment. This is because some coun-tries have laws and regulations that may govern the confi-dentiality and privacy of the stored data. Thus, data ownersmay need to make sure that their cloud providers do not com-promise the SLA contract and move their data into anothergeographic location.
The aim of the proposed scheme is to enhance the pro-posed GeoProof in [1] in order to encompass the dynamicPOS schemes and reduce the extra time resulted from compu-tational overhead at the server side. The proposed GeoProofprotocol in [1] requires the same computational overhead atthe cloud side as is used in the underlying POS protocol inorder to compute the required proof and send it back to theverifier. This computational overhead may incur a significanttime delay that will affect the accuracy of the geographiclocation. Even a relatively small time delay is significant;using measurements of Katz-Bassett et al. [8] and [1], esti-mates that data could travel up to 200 km in 3 ms greatlydegrading the accuracy of location estimates.
Thus, the main difference is that this new scheme doesavoid or delay all significant computational parts of the proofat the provider side. This will produce a saving in time for theserver response, which will increase the location accuracyof the stored data. This is achieved by moving these com-putations from the cloud side into the verifier side withoutundermining the security of the underlying POS protocol.
In regard to the security requirements, all security require-ments are maintained as in the underlying POS protocol thathave been used in the enhanced GeoProof. For instance, dataconfidentiality is preserved by allowing the data owner toencrypt the data before sending it to the cloud storage. Dataintegrity depends on the POS scheme used; for example, ifthe DPOR scheme [11] is used, then the data integrity ispreserved by running the default verification process thatinvolves verifying the cryptographic tags (σ ) associated witheach data block. Data availability also depends on the originalPOS scheme used. For example, with DPOR scheme [11], thedefault verification process gives the verifier a high assurancethat the whole data file is available and stored at the remotestorage.
5 Future work
Future work can apply our techniques to more POS schemessuch as the provable data possession protocol [2] anddynamic provable data possession protocol [5].
One suggested future work for this research is to includethe processed data along with the stored data as part of one
complete solution. This could be accomplished by utilisingsome recent cryptographic techniques that allow operationson encrypted data. Such operations may be performed bythe cloud provider as a service to the user, without requiringthe user to decrypt the data. Searchable and homomorphicencryptions are examples of these techniques. So, customerscan maintain the confidentiality of their data while stored inthe cloud and also they can process it.
Another future work is to propose a proof of replicationthat the data owner can run from multiple locations simul-taneously to prove that the data are replicated over multipleand separated data centres. This could be done by running theGeoProof from multiple locations simultaneously. In general,the data owner replicates its data over multiple and separatedlocations. Then, for each selected data centre, the attachedverifier with each requested server will run the GeoProof withthat server. The verifier will start the challenge-response pro-tocol by sending the selected block index i to the prover (P)and starts the clock (timing). The prover in the other sideneeds to respond by sending back the proof transcript. Atthe end, the verifier will be able to verify the retrieved prooftranscripts and assure the location of the stored data.
Another future direction is to do some practical implemen-tations. Given sufficient resources, it would be interesting tomake practical tests to examine how accurately geographiclocation can be measured in practice. Simulation and coop-erating with cloud provider are examples of such implemen-tations.
References
1. Albeshri, A.A., Boyd, C., Nieto, J.M.G.: Geoproof: proofs of geo-graphic location for cloud computing environment. In: 3rd Interna-tional Workshop on Security and Privacy in Cloud Computing Partof the 32nd International Conference on Distributed ComputingSystems Workshops (ICDCS 2012), pp. 506–514. IEEE, Macau,China (2012)
2. Ateniese, G., Burns, R., Curtmola, R., Herring, J., Kissner, L.,Peterson, Z., Song, D.: Provable data possession at untrusted stores.In: Proceedings of the 14th ACM Conference on Computer andCommunications Security, CCS ’07, pp. 598–609. ACM, NewYork, NY (2007)
3. Benson, K., Dowsley, R., Shacham, H.: Do you know where yourcloud files are? In: Proceedings of the 3rd ACM Workshop on CloudComputing Security Workshop, CCSW ’11, pp. 73–82. ACM, NewYork, NY (2011)
4. Chow, R., Golle, P., Jakobsson, M., Shi, E., Staddon, J., Masuoka,R., Molina, J.: Controlling data in the cloud: outsourcing computa-tion without outsourcing control. In: Proceedings of the 2009 ACMWorkshop on Cloud Computing Security, pp. 85–90. ACM (2009)
5. Erway, C., Küpçü, A., Papamanthou, C., Tamassia, R.: Dynamicprovable data possession. In: Proceedings of the 16th ACM Con-ference on Computer and Communications Security, CCS ’09, pp.213–222. ACM, New York, NY (2009)
6. Juels, A., Kaliski, B.S. Jr.: PORs: proofs of retrievability for largefiles. In: Proceedings of the 14th ACM Conference on Computer
123
A. Albeshri et al.
and Communications Security, CCS ’07, pp. 584–597. ACM, NewYork, NY (2007)
7. Kamara, S., Lauter, K.: Cryptographic cloud storage. In: Sion, R.,et al. (eds.) Financial Cryptography and Data Security, vol. 6054 ofLecture Notes in Computer Science, pp. 136–149. Springer, Berlin(2010)
8. Katz-Bassett, E., John, J.P., Krishnamurthy, A., Wetherall, D.,Anderson, T., Chawathe, Y.: Towards IP geolocation using delayand topology measurements. In: Proceedings of the 6th ACM SIG-COMM Conference on Internet Measurement, IMC ’06, pp. 71–84.ACM, New York, NY (2006)
9. Peterson, Z.N.J., Gondree, M., Beverly, R.: A position paper ondata sovereignty: the importance of geolocating data in the cloud.In: Proceedings of the 8th USENIX Conference on NetworkedSystems Design and Implementation (2011)
10. Shacham, H., Waters, B.: Compact proofs of retrievability. In: Pro-ceedings of the 14th International Conference on the Theory andApplication of Cryptology and Information Security: Advances inCryptology, ASIACRYPT ’08, pp. 90–107. Springer, Berlin (2008)
11. Wang, Q., Wang, C., Li, J., Ren, K., Lou, W.: Enabling public veri-fiability and data dynamics for storage security in cloud computing.In: Proceedings of the 14th European Conference on Research inComputer Security, ESORICS’09, pp. 355–370. Springer, Berlin(2009)
