PASSAT: Single Password Authenticated Secret-Shared Intrusion-Tolerant Storage with Server Transparency
PPASSAT: Single Password Authenticated Secret-SharedIntrusion-Tolerant Storage with Server Transparency
Kiavash Satvat ∗ , Maliheh Shirvanian § , Nitesh Saxena + University of Illinois at Chicago ∗ Visa Research Lab § University of Alabama at Birmingham + [email protected] ∗ , [email protected] § , [email protected] + ABSTRACT
In this paper, we introduce PASSAT, a practical system to boostthe security assurance delivered by the current cloud architecturewithout requiring any changes or cooperation from the cloud ser-vice providers. PASSAT is an application transparent to the cloudservers that allows users to securely and efficiently store and accesstheir files stored on public cloud storage based on a single masterpassword. Using a fast and light-weight
XOR secret sharing scheme,PASSAT secret-shares users’ files and distributes them among 𝑛 publicly available cloud platforms. To access the files, PASSAT com-municates with any 𝑘 out of 𝑛 cloud platforms to receive the sharesand runs a secret-sharing reconstruction algorithm to recover thefiles. An attacker (insider or outsider) who compromises or colludeswith less than 𝑘 platforms cannot learn the user’s files or mod-ify the files stealthily. To authenticate the user to multiple cloudplatforms, PASSAT crucially stores the authentication credentials,specific to each platform on a password manager , protected underthe user’s master password. Upon requesting access to files, theuser enters the password to unlock the vault and fetches the au-thentication tokens using which PASSAT can interact with cloudstorage. Our instantiation of PASSAT based on (2, 3)-XOR secretsharing of Kurihara et al., implemented with three popular storageproviders, namely, Google Drive , Box , and
Dropbox , confirms thatour approach can efficiently enhance the confidentiality, integrity,and availability of the stored files with no changes on the servers.
Cloud storage services are widespread and popular online servicesused for archiving, backup, and data sharing. A variety of serviceproviders, including Amazon Web Services, Dropbox, MicrosoftAzure, Box, and Google Drive, offer cloud storage and file synchro-nization through application-based (and browser-based) interfaces.Despite the evident advantages of cloud storage, security and pri-vacy concerns refrain customers from full adoption of the cloudservices [3, 42]. The current implementation demands customers’trust on providers, whereby users cannot monitor and assure thesecurity (including confidentiality and integrity) of their data.Various approaches were proposed to enhance the security ofcloud storage through encryption, replication, erasure code, andsecret-sharing [14, 19, 21, 26, 35, 37, 44, 45]. However, given thecomplication of their use by non-expert users, key managementconcerns, encryption bans in some countries, and additional com-putation/communication overhead they may pose in practice, theadoption of them still remains questionable. Critically, many ofthese approaches require changes on the side of the public cloudservice providers, which may not be possible unless these providers cooperate, and therefore, most of these approaches cannot be cur-rently deployed from the user-side.We propose PASSAT, an efficient password-controlled storageparadigm to address the security concerns in storing users’ privatedata on untrusted platforms, without any need for modifications orcooperation from currently available platforms. PASSAT employsthe notion of secret sharing to improve the confidentiality, integrity,and availability of the stored data. In the PASSAT protocol, the userhas some private data 𝑠𝑐 that she wants to store and protect, andbe able to later access on the basis of a single password 𝑝𝑤 . PAS-SAT employs a fast and light-weight XOR secret sharing schemeto distribute the file ( 𝑠𝑐 ) into 𝑛 multiple distinct shares and storesthese shares across public cloud storage platforms. To access thefiles, PASSAT communicates with any 𝑘 out of 𝑛 cloud platformson the input 𝑝𝑤 from the user and runs a secret-sharing reconstruc-tion procedure to recover the file. An attacker should compromiseor collude with at least 𝑘 platforms to learn the user’s files. Saiddifferently, an attacker who compromises or colludes with up to 𝑘 − services and learns the corresponding up to 𝑘 − shares ofthe files cannot learn anything, in the information theoretic sense,about the files themselves. This enhances the security of 𝑠𝑐 againstnot only the malicious outsider attacks but also the insider attacks(it is known that the cloud service providers may peek into userdata [13, 29]). Moreover, none of the existing cloud providers areHIPAA compliant, and there is no certification recognized by theUS Department of Health and Human Services for HIPAA compli-ance. Complying with HIPAA is a shared responsibility betweenthe customer and cloud services, which can be addressed usingPASSAT.In addition to improving the confidentiality and privacy of thestored data, PASSAT enhances its integrity because any maliciousmodification of less than the 𝑘 stored shares can be detected by theuser during the reconstruction process as such reconstruction willyield random garbage or meaningless data. Protecting the integrityof the stored data is important as a malicious or compromised cloudprovider is able to modify the data contents. Furthermore, PASSATimproves the availability of the data and protects it against deletionby the service providers (as previously reported in [22]) becausethe data remains available as long as 𝑘 valid shares are accessible.To access the information stored in the cloud, PASSAT shouldauthenticate to each cloud. The simple password authenticationis not a rational approach, since in that case, the cloud providershould share the user password with all third-party applications(including PASSAT) granting limitless access to all the applications.There are multiple authentication protocols implemented by publiccloud providers for access of the third party application. For thesake of simplicity, we assume that the cloud storage has deployed a r X i v : . [ c s . CR ] F e b pen Authorization (OAuth) authorization framework [10] as itis the common approach that cloud services use to provide clientapplications with secure delegated access. The “User Authentica-tion” type defined by OAuth 2.0 [10], uses an “Access Token” for aspecific user and application pair. Using the access token, PASSATcan interact on behalf of the user with the cloud to perform theoperations (e.g., upload, and download). PASSAT crucially storesthe authentication credentials (e.g., the access token), specific toeach platform on a password manager , protected under the user’ssingle (master) password. Upon requesting access, the user entersthe password to get the authentication tokens from the passwordmanager to interact with the storage providers. PASSAT vs. Other Schemes:
To compare our approach with theexisting work, we consider as the “baseline”, a cloud storage systemthat stores the files ( 𝑠𝑐 ). Such a system does not provide any securityassurance. However, we can assume an “enhanced-baseline” systemin which the user duplicates the files and store them on 2 platformsfor higher availability assurance and also, 𝑠𝑐 could get encryptedon the client-side under an encryption key (which itself shouldbe protected by the client). For comparison, we also consider thepassword-protected secret sharing (PPSS) protocol, formalized in[14], in which 𝑠𝑐 is secret-shared and distributed among multipleplatforms and can be accessed on the basis of a single password 𝑝𝑤 (by interacting with 𝑘 out of 𝑛 servers). In all cases, the interactionbetween the client machine (from which the user accesses thefiles) to the cloud storage is assumed to be authenticated with anaccess token 𝑡𝑘 . PASSAT provides the following main properties simultaneously as presented in Table 1:(1) Server Transparency:
PASSAT is a client application that in-teracts with cloud servers through the API calls defined by thecloud provider. Therefore, PASSAT can easily get integratedwith current popular cloud platforms with no modification onthe servers. The baseline system is also server transparent, as isthe case for the enhanced-baseline system since it considers theencryption and replication load to be delegated to the users. ThePPSS system, however, does not provide server-transparencysince it requires reconstructing the shares through the PPSSprotocol running between the client (on input 𝑝𝑤 ) and the cloudservers.(2) Efficiency:
Use of the XOR secret sharing of [31] enhances theperformance of the secret sharing, and therefore, even moder-ately large files can be secret-shared with minimal overhead(as can be observed in our evaluation presented in Section 6).Compared to the enhanced-baseline system, PASSAT is moreefficient due to the lower secret sharing delay compared to theclient-side encryption. Also, in other secret sharing protocols,the delay imposed by the secret sharing algorithm makes itinefficient to secret-share large files. Therefore, most of the pro-posed secret sharing techniques use encryption in combinationwith secret sharing (to distribute the encryption keys) to protectlarge files in the cloud. That is, large files are stored in the cloudencrypted under an encryption key that is secret-shared amongmultiple platforms each having piece of the encryption key.(3)
Protection of Access Tokens:
PASSAT employs a passwordmanager to securely store the tokens on the password managerand protect it under the master password to provide secure and easy authentication to the cloud service providers. Thisapproach improves the accessibility and security of the tokens.Storing the token on the client application is not secure againstclient compromise. Besides, it would make it difficult to accessthe cloud storage from different clients because the token shouldbe copied on every client from which the user wants to accessthe files. Note that since the token is typically a long stringof random characters, it is not reasonable to ask the user tomemorize it. We can also apply a second layer of secret sharingon the access tokens and share them among multiple passwordmanagers to further improve the security by lifting the trust onthe password managers. None of the other approaches providethis useful feature.
Our Contributions:
Our novelty lies in building an intrusion-tolerant outsourced storage system, via a careful combination ofknown techniques (secret sharing and password management), thatdoes not require changes to the server side or heavy encryption onthe client side, and is therefore readily deployable. Our contribu-tions are as follows:(1)
System Design:
We introduce PASSAT, a password-controlledsecret file sharing client application, that can securely and ef-ficiently store files on public cloud storage services. PASSATemploys a light-weight, provably secure XOR secret sharingalgorithm to secret-share and reconstruct files. Each share of fileis stored in clear text on one public storage but does not revealany information about the file, unless a threshold of servicesget compromised or colludes with one another. PASSAT storesaccess tokens, required to access/authorize the file operations,on a password manager protected under the user’s master pass-word. To store the file shares and to reconstruct the file, theuser enters the master password to unlock the tokens stored onthe password manager so that PASSAT can authenticate to thecloud platforms.(2)
PASSAT Implementation as a Client-Side Application:
As its practical instantiation, we develop a PASSAT client ap-plication in Python based on (2, 3)-XOR secret sharing. Ourapplication interacts with Google Drive, Box, and Dropbox tostore file shares and restore them to reconstruct the file. Theinteraction with the cloud platforms is through the API callsdefined in the SDKs and the user authentication is based onaccess tokens defined by the cloud for the user and PASSAT ap-plication. The access tokens are stored in LastPass and PASSATuses LastPass API to fetch them on the master password inputfrom the user.(3)
Evaluation of PASSAT:
We evaluated our implementation ofPASSAT in terms of average delay incurred to share multiplefile sizes, store them on each cloud, recollect the shares from thecloud, and reconstruct the file with any combination of 2 outof 3 shares. Our evaluation shows that PASSAT is efficient anddoes not impose more that 5% overhead over the upload anddownload operation. Therefore, it can instantly be incorporatedin practice. Based on our evaluation, we got insights on theoptimum size of the files and share blocks.
Paper Outline:
The rest of the paper is organized as follows. Sec-tion 2 provides background on information dispersal and secretsharing. Sections 3 presents the abstract design of PASSAT. Section able 1: A comparison between PASSAT and other related schemes
Baseline Enhanced-baseline (2, 3)-PPSS (2, 3)-PASSATConfidentiality
No Yes Yes Yes
Integrity
No Yes (manipulation of 1 share) Yes (manipulation of up to 2 shares) Yes (manipulation of up to 2 shares)
Availability
Yes (availability of 1 out 1) Yes (availability of 1 out 2) Yes (availability of 2 out of 3) Yes (availability of 2 out of 3)
Data Deletion Resistance
No No Yes Yes
Storage Cost × secret size 2 × secret size 3 × secret size 3 × secret size Server Transparency
Yes Yes No
YesEfficiency
Data stored in clear text Encryption (costly) Secret sharing, Encryption,PPSS to reconstruct encryption key
Secret sharing (fast)Token protection
No No No
Yes
Data Dispersal.
Several methods are proposed to securely dispersethe data [17, 21, 30, 36, 38]. The secret sharing notion introducedby Shamir and Blakley in 1979 [20, 38] is a common approach forsecurely dispersing data. It refers to the method of distributing asecret between a group of participants such that each participant hasa portion of the secret and only authorized subsets of participantscan reconstruct it, i.e., any number of shares fewer than a certainthreshold infers no meaningful information about the secret.
XOR Secret Sharing.
Since the introduction of the secret sharingnotion several constructions of secret sharing schemes have beenintroduced by researchers [16, 18, 25]. However, one major problemwith many of the proposed approaches including Shamir [38] isthe noticeable computational cost for both distribution and recov-ery [31]. In this paper, we build our system based on a relativelynew and efficient secret sharing scheme introduced by Kurihara etal. [31]. This scheme uses light-weight XOR operation for secretsharing and reconstruction. Kurihara et al. [31] (k, n)-thresholdscheme enables to make and distribute 𝑛 shares following the XORsecret sharing algorithm. The secret can be recovered by concate-nating 𝑘 out of 𝑛 secrets following the reconstruction algorithm.The XOR operation offers a fast distribution and recovery of secretand reduces the computational cost compared to other schemeswith complex operations. For example, unlike the Shamir’s scheme,which uses arithmetic in a finite field F of size P (a prime number)and therefore has a heavy computational cost due to the processingof ( 𝑘 − ) -degree polynomials, the XOR uses light-weight bitwiseoperations that is much faster.We used an instantiation of this pro-tocol with 𝑘 = and 𝑛 = , where 𝑛 is the number of shares and 𝑘 is the minimum number of shares required to recover the secret. Generating Shares:
At the share generation stage, (2, 3)-XORthreshold scheme divides 𝑑 -bit secret 𝑆𝐶 into two pieces of 𝑆𝐶 and 𝑆𝐶 each of size 𝑑 / -bit. For generating the shares we pick arandom number 𝑅 of size 𝑑 -bit. The 𝑑 / higher bits of the first share 𝑐 are created by XORing 𝑑 / -bit string of zeros with 𝑅 (the higher 𝑑 / bits of 𝑅 ). The 𝑑 / lower bits of 𝑐 are created by XORing 𝑆𝐶 with 𝑅 (the lower 𝑑 / bits of 𝑅 ). The second share ( 𝑐 ) is createdby XORing 𝑅 with zeros and 𝑆𝐶 with 𝑅 . The third share ( 𝑐 ) isgenerated by XORing 𝑆𝐶 with 𝑅 , and 𝑆𝐶 with 𝑅 . Reconstructing Secret:
Every two parties can jointly reconstruct 𝑆𝐶 by performing simple XOR operations. To recover the secret 𝑆𝐶 using 𝑐 and 𝑐 , a simple XOR of shares results in the productionof 𝑆𝐶 on the higher 𝑑 / bits and 𝑆𝐶 ⊕ 𝑆𝐶 on the lower 𝑑 / bits.Another round of XOR between these two ( 𝑆 ⊕ ( 𝑆 ⊕ 𝑆 ) results in 𝑆𝐶 . Swapping the order of recovered 𝑆𝐶 and 𝑆𝐶 blocks result inthe reconstruction of the secret 𝑆𝐶 . Similarly the 𝑐 ⊕ 𝑐 produces 𝑆 ⊕ 𝑆 on the lower 𝑑 / bits and 𝑆𝐶 on the higher 𝑑 / bits. Anotherround of XORing these two blocks ( ( 𝑆 ⊕ 𝑆 ) ⊕ 𝑆 ) recovers 𝑆𝐶 .Finally, a simple 𝑐 ⊕ 𝑐 operation reconstructs the secret 𝑆𝐶 . Parties:
Following parties involved in the protocol: • 𝑈 : denotes a user who has some information that she wants tostore and protect. • 𝑆 , ..., 𝑆 𝑛 : denotes n cloud providers. We let each server 𝑆 𝑖 pickthe access token 𝑡𝑘 𝑖 • 𝐶 : is the cloud storage client from which 𝑈 stores and retrieve 𝑠𝑐 . 𝐶 interacts with 𝑆 through the 𝑆 API calls. • 𝑀 : the password manager that stores access tokens 𝑡𝑘 𝑖 under theserver name 𝑆 𝑖 , and protects them by a single master password 𝑝𝑤 .User’s 𝑠𝑐 is distributed among 𝑆 ’s through a secret-sharing pro-tocol (as is defined next) and can later be accessed by interactingwith 𝑘 out of 𝑛 servers on the basis of a single password 𝑝𝑤 andrunning the reconstruction protocol as follows: Secret Sharing:
Steps taken to secret-share a file are as follow: • Step1-C: Secret-share the secret file 𝑠𝑐 into shares ( 𝑐 , ..., 𝑐 𝑛 )• Step2-C,M: C interacts with 𝑀 to retrieve 𝑡𝑘 𝑖 on input 𝑝𝑤 • Step3-C,S: C authenticates to 𝑆 𝑖 using 𝑡𝑘 𝑖 • Step4-C,S: C uploads 𝑐 𝑖 on 𝑆 𝑖 Reconstruction:
Steps taken to reconstruct a file: • Step1-C,M: C interacts with 𝑀 to retrieve 𝑡𝑘 𝑖 on input 𝑝𝑤 • Step2-C,S: C authenticates to 𝑆 𝑖 using 𝑡𝑘 𝑖 • Step3-C,S: C downloads 𝑘 out of 𝑛 shares 𝑐 𝑖 from each server 𝑆 𝑖 • Step1-C: Reconstructs the secret file 𝑠𝑐 from shares ( 𝑐 , ..., 𝑐 𝑘 ) Threat Model:
In PASSAT threat model, we consider that eachsingle cloud provider may get compromised through a maliciousinsider or outsider attack. Therefore, the user should not be obli-gated to trust any single cloud provider. The data stored on thecompromised cloud may be learned, lost, or tampered, temporar-ily or permanently. We assume that an attacker has access to no or tagPassword Manager Upload File Download FileMerge f , f , …, f n to F PASSATRequest Authentication TokensAuthentication Tokens
If File F > threshold t Split F to f , f , …, f n Share Secret Reconstruct Secret
Figure 1: PASSAT high-level view architecture more than 𝑘 − shares, otherwise the attacker can reconstructthe secret file from the learned secret shares, alter the file by mod-ifying/replacing the shares, or make disruption in accessing thefile. Since we do not trust the cloud providers, we assume that noencryption is applied on the files. We also assume that no morethan 𝑘 − attackers collude to share the learned secrets.We further assume that 𝑀 is trusted and we consider a securecommunication channel between 𝐶 and 𝑀 (as is the case whenusing real-world password manager). Note that this property canalso be replaced with no trust on the password manager if we adda second layer of secret sharing on 𝑡𝑘 ’s to secret-share and storethem on multiple password manager. We will discuss this solutionand other mitigations in Section 7. Security against Storage Compromise:
Similar to other (k, n)-secret sharing approaches, we guarantee the security of the systemas long as the attacker has access to no more than 𝑘 − shares. If eachand every 𝑘 server gets compromised by individual attackers, aslong as attackers do not collude, the security is guaranteed. In sucha system, the security is compromised only in a situation where anattacker (or more than one attacker who can collude) can retrieve 𝑘 shares. The system also guarantees that a benign user with accessto 𝑘 shares to be able to reconstruct the whole secret. The availabil-ity of the data (and deletion-resistance) is guaranteed if at least avalid set of 𝑘 servers/secret shares are available. The (k, n)-secretsharing can also protect the integrity of the data (thereby providemodification-resistance) since modified data can be detected by theuser while reconstructing the data, as such reconstruction involvingmodified secret shares will result in a meaningless random output. Security against Attacks on Password Manager:
Since we as-sume that tokens are secured in the password manager an attackercan only access tokens by launching online guessing attacks againstthe master password. TThe attacker who has access to the pass-words database (being protected under the master password) triesto guess the password to disclose (decrypt) the tokens. After eachguessing attack the attacker should then try to access the storageusing the disclosed tokens in an online attempt to authenticate to the storage server. Such an attempt may or may not be successful,i.e., the tokens may or may not be valid. However, the mitigationagainst online attacks is straightforward and has already been de-ployed by the service providers through rate limiting. Hence, evenif the attacker gets access to the password files, obtaining the tokensstill requires launching an online guessing attack, which can bedetected by the servers. Offline attacks on the password file are alsonot possible since the stored tokens have high entropy and cannotbe guessed, unlike a password driven from a known dictionary.
PASSAT Components.
PASSAT consists of three main and oneoptional components:(1)
Secret Generator.
This component receives a secret file as aninput and secret-shares it into 𝑛 shares. It also reconstructs thefile from at least 𝑘 out of 𝑛 shares.(2) Middleware.
This component act as the interface between theuser, the password manager, and the cloud services.(3)
Password Manager.
The password manager is used as a secureauthentication token vault that stores access tokens needed toauthenticate PASSAT to the clouds. PASSAT authenticates tothe password manager using the user (master) password.(4)
Splitter.
XOR operation can be daunting and can slow down theprocess for large files. Therefore, PASSAT optionally deploys afile splitter that can break a large file into smaller files and tagthem for the later reconstruction of the file.Figure 1 demonstrates the overview of PASSAT. We assumethat the user has accounts with 𝑛 public cloud services. OptionallyPASSAT can be provided as a service with no need for the userto register an account with each storage service. Each uploadingfile is secret-shared and each share is stored on one of the 𝑛 cloudservices. PASSAT can split larger files into smaller files beforesecret-sharing (details is discussed in Section 5 and Section 6). Thedownload procedure starts by receiving the shares from the storageand reconstructing the file following the secure reconstructionprotocol. The long-lasting authentication information is stored in plitter User Secret Share Password ManagerMiddleware File F F < T Check if F> T Share Secret
Clouds D r o pb o x F > T Split and tagF to f , f , …, f n File F Shares S , S , …, S n Auth Tokens (tk ,tk ,tk ) upload secret s B o x G oo g l e upload secret s upload secret s authenticate tk authenticate tk authenticate tk Send f , f , …, f n Share SecretShares S , S , …, S n Request AuthTokens
Figure 2: PASSAT components interaction on uploading afile the password manager once and can be retrieved any time theuser needs to upload/download files. To fetch the authenticationinformation from the password manager the user should enter the(master) password, which unlike the long-lasting authenticationinformation could be updated frequently. We can assume that anauthentication session can remain active for a limited duration oftime (e.g., as long as the PASSAT application is open).Figure 2 demonstrates the PASSAT operational diagram for up-loads. The process starts by the user entering a file name to be storedsecurely on the cloud. PASSAT receives the file and using the Se-cret Sharing component distributes it into 𝑛 shares. Middlewareauthenticates the system to the cloud services using the fetchedcredentials and uploads the shares into the cloud services. If thesize of the file is larger than a certain limit, PASSAT can optionallysplit it into smaller files to improve efficiency.Figure 3 demonstrates the operational diagram for downloads.When the user requests a file to be downloaded, PASSAT Mid-dleware authenticates to 𝑘 out of the 𝑛 services and downloadsthe previously stored shares. The Middleware passes the receivedshares to the Secret Sharing component to reconstruct the file. Secret Sharing.
This component is responsible for generatingshares from the secret file and reconstructing the secret file fromthe shares. The component employs (2, 3)-XOR threshold scheme(discussed in Section 2) to construct and distribute three file sharesout of a file in such a way that at least two file shares are requiredto reconstruct the original file and having access to one of the file-shares does not reveal any information about the original file. Forthe process of generating shares, the component reads through thefile and chops the file into blocks of 𝑑 -bits, applies the (2, 3)-XORsecret sharing on each block, and writes the outputs into threedifferent shares/files. In cases where the file size is not a factorof 𝑑 -bits the component pads the file tail with a string of zeros.For the reconstruction, PASSAT takes two shared files as the inputand reconstructs them in blocks of 𝑑 -bit. The possible padding isremoved after reconstruction. Splitter User Secret Share
Password Manager
Middleware
Request Filecheck tag reconstruct secret(s)
Clouds D r o pb o x Rejoin file FSecret(s) Shares s1,s2,s3 Auth Tokens (tk ,tk ,tk ) retrieve secret s B o x G oo g l e retrieve secret s retrieve secret s authenticate tk authenticate tk authenticate tk Return File F Request AuthTokens
Figure 3: PASSAT components interaction on retrieving afileMiddleware.
As a central component Middleware interacts withcloud storages and the password manager, and offers a user-interface, which allows users to upload and retrieve their data.This component uses the APIs and received master password fromthe users, and retrieves the cloud tokens for further interactionwith storages.
Single Authentication Through a Credential Vault.
To list,upload, or download files on popular commercial cloud storage,often the cloud provider requires the apps to authenticate using along-lasting authentication token (as will be elaborated in Section 5).PASSAT just like any other app that uses the cloud API to performfile operations requires to authenticate itself to get access to thefile directory. One option is for the user to input the credentialinformation at every access. Since these tokens are often a series oflong and randomized characters, it would not be feasible (or usable)to ask the user to provide them for each cloud storage per eachaccess request. Another option is to store the long-lasting tokens onPASSAT (e.g., hard- coding the tokens on the app), however, in thatcase any unauthorized access (even temporarily) to the PASSAT appmay lead to exposure of the tokens and thereby access to the filesfrom the same PASSAT client or any other maliciously developedapp. Also since the user may access the files from multiple clients,the access tokens should be copied on each client and synchronizedif updated, which increases the security risk. Hence, we store theauthentication information in the password manager.
File Splitting.
Over the past years, the secret sharing schemeshave been mostly used in the context of small secrets, mainly todistribute secret keys and to protect them securely. Computationalcost of sharing and reconstructing secrets makes it infeasible touse this technique on large files. To overcome this problem, first,we used a fast and light-weight secret sharing scheme [31]. Thescheme utilizes a simple and low cost operation of XOR for con-structing and reconstructing shares and secret. Compared to thetraditional approaches (e.g., Shamir’s secret sharing schemes [38])XOR requires a significantly less computational time and poses f f t F f c f c f c f t c f t c f t c f c f c f c … . … . S S S File F Splitted F … . … . (2, 3)-XOR Secret Shared Figure 4: Splitting a file to smaller files and sharing themacross different cloud services considerably less overhead. Second, for the further enhancementand to avoid impelling huge computation of XORing large file, wedesigned a splitter that breaks larger files into smaller files. Break-ing larger files into smaller files accelerates the process wheneverthe file size passes a specific threshold, which may impact the se-cret sharing computation time (as will be discussed in Section 6).Splitting a large file into small files enables the system to reduce thecomputational time by dealing with smaller files. For future recon-struction Splitter tags each of the new files. Assuming that we havea finite file f , the splitter split the file into { 𝑓 , 𝑓 , 𝑓 , ..., 𝑓 𝑡 } . Thesesmaller files later are the input to the secret sharing component.Figure 4 shows an overview of breaking a file. Although PASSAT can be deployed with any other number for 𝑘 and 𝑛 , we prove the practicality of our approach with 𝑘 = ,and 𝑛 = (tolerating compromise or unavailability of one ser-vice at a time). Appendix Algorithms 1 and 2 delineate PASSATapproach on sharing and reconstructing secret. Considering thecurrent server level agreement and cloud uptime the (2, 3) seemsto be a resilient threshold parameter and offers an acceptable levelof availability. These parameters have also been adopted before(e.g., [2, 4, 9, 11]). While the security enhances with the increasein 𝑘 and 𝑛 (in terms of making the system more reliable againstpossible cloud unavailability and/or compromise), the storage costand shares computation time grows as 𝑘 and 𝑛 increase, which maymake the system infeasible for larger files in practice.We developed PASSAT as a client-side application in Python. Weused the libraries offered by the cloud storage services and pass-word managers in our deployment. In our implementation, duringthe setup phase, the user requires to register with the desired cloudservices, namely, Google Drive [7], Box [6], and Dropbox [5], andobtain the access tokens required for further communication withthe cloud only. In this proof of concept deployment registeringthe users was a simple implementation choice, however, storageproviders offer several other authentication mechanisms for thirdparty apps that do not require user registration to support differ-ent use cases. Alternatively, we can assume PASSAT as a service provider which generates and manages the accounts and interactswith third party storage service providers as will be discussed in Sec-tion 7. PASSAT does not record the user’s credentials locally by anymeans. Instead, the user stores the access tokens on LastPass pass-word manager [8] under the server’s name during the initial setup.To securely communicate with the storage, PASSAT fetches theaccess tokens from the password manager using LastPass Pythonlibraries. The access tokens are used by PASSAT to securely connectto the cloud and perform file operations (e.g., listing, uploading anddownloading files from the cloud). As mentioned earlier, for thesake of simplicity, we assume that the password manager is trustedand store the tokens only on one manager.After setting up the system (registering with the storage servicesand storing the tokens on LastPass), the user can perform the file op-erations by inputting the file operation type (upload, or download),the file address for uploading, the file name for downloading, andthe (master) password to connect to LastPass to PASSAT. For thefile upload operation, PASSAT works as follows, first, the programdecides whether it is required to break down the larger file intosmaller files. The smaller files are tagged by adding a sequentialnumber to their name for easier merge during the download proce-dure. The decision is made based on a dynamic threshold which canbe defined to reduce the computational time for generating and re-constructing the secret. Our evaluation section gives some insightson the optimum file sizes. PASSAT, continues with secret-sharingthe file by processing the file block by block and applying the (2,3)-XOR secret sharing discussed in Section 2 on each block of size 𝑑 -bit. Note that due to the underlying hardware and processingspecification, running the secret-sharing on a file of size 𝑑 -bit is notefficient. Therefore, as will be discussed in our evaluation the sizeof 𝑑 is picked based on the optimum performance. PASSAT appendsthe 𝑑 -bit shares to form each file share to be stored on the cloudservices. The system then uses the provided LastPass password tofetch the access token for each of the three storage services andthen makes the API calls to each cloud using the access token tostore the file. Similarly, for the file download operation, PASSATcommunicates with any 2 of 3 cloud storage services using theauthentication token received from LastPass to get the file shares.PASSAT applies the (2, 3)-XOR reconstruction procedure on thereceived file shares block by block and appends the result to re-construct the file. For larger files, PASSAT receives all the split fileshares, reconstruct the split files by applying the (2, 3)-XOR recon-struction procedure, and then merges all the reconstructed sharesto form the actual file. Following sections describe this procedurein detail. Secret Sharing.
This includes two main functions of constructionand reconstruction written in Python. The construction functionreads the file in 𝑑 -bit block and writes them into the shares. The 𝑑 -bit block is appended to form a file share that is stored in thecloud. Reconstruction rebuilds the file from any two shares. The fileshares are processed at 𝑑 -bit block sizes and outputs are appendedto reconstruct the file. Interaction with Cloud Services.
PASSAT generates three filesshares, each one should be stored in one of the three cloud storages,namely, Google Drive, Box, and Dropbox. We store each of thesefile shares using the APIs provided by each of these companies.We used the Drive API V3 through google-api-python-client . , . . . T i m e i n M illi s e c o nd Share SecretShamir PASSAT 02004006008001000120014001600 10KB 100KB . , . . . T i m e i n M illi s e c o nd Reconstruct SecretShamir PASSAT
Figure 5: Shamir secret sharing and PASSAT Latency com-parison
Python package version 1.6.4 for interaction with Google Drive.Our Google Drive upload function uses
MediaFileUpload to definethe file and runs an HTTP POST request to create the file onDrive. Our Google Drive download function creates an HTTP GETrequest to download the file. We used Box API through boxsdk
Python package version 2.0.0a11 for operations on Box platform.Communication with Box API is similar to Google Drive throughHTTP POST and GET requests. For Dropbox, we used the DropboxAPI V2 through dropbox
Python package version 8.5.0 to uploadand download files. Similar to the Google Drive and Box API wemake HTTP POST and GET requests to upload and download thefiles.
LastPass.
We used LastPass [8] as a popular password manager andbased the development on lastpass-python package to interactwith LastPass and leverage the provided functionality. Our currentimplementation setup requires users to login and store their accesstokens into their local LastPass application, though the processcan be automated as an additional option. Once the credentialsare stored, PASSAT uses Lastpass API to retrieve the cloud accesstokens.
Splitting and Merging.
We deployed a simple and fast file splittingto break larger files 𝑓 into smaller files using a threshold that canbe defined based on the performance of the operations as will bediscussed in Section 6. We created a Python function, which readsthrough the file and splits and tags it for the later reconstruction.While our current splitting function is only able to manage thetext files, as a part of future enhancement we aim to expand andempower this function to handle other file types. Prior studies have discussed and evaluated the performance of dif-ferent schemes [27, 31, 37, 40]. [31] compared the XOR and Shamir’ssecret sharing. [37] compared their system with Rabin and Shamirapproach. [40] and [27] reported detail comparisons of various ap-proaches. We further compared our approach against the popularShamir’s scheme which seems to be the fastest schemes [27, 40].Figure 5 shows the differences in terms of latency between twoapproaches. We picked two file size of 10KB and 100 KB as anycomputation (1MB and 100MB) result in a significant increase inShamir’s secret computation. As it can be seen our approach hasfar less latency compared to the popular Shamir’s approach. Webriefly mentioned the heavy computational cost of Shamir’s secretsharing in contrast with XOR (Sec. 2) and provided a detailed quali-tative evaluation between baseline, enhanced baseline, and PASSAT(Table 1). Here, we analyze the performance of PASSAT in terms of the “storage cost” and “latency” . We evaluate the overhead com-pared to the baseline (uploading and downloading files) to provethe viability of such approach and demonstrate that the securitybenefits come at a reasonable cost. We have not performed any codeoptimization, therefore, the delays reported in this section are theupper side estimation of the delay. Since we do not have any server-side changes we consider the storage providers as a black box anddo not have any evaluation of the internal processes of the cloudservices. Therefore, for the baseline system, we only measured theinteraction time between our application and the cloud storage todemonstrate the average delay of file uploading and downloading.We ran our test on a 64-bits Windows platform (6.1, Build 7601)running on a 8.00 GB (7.87 Usable) RAM, and an Intel(R) core(TM)2quad q9550 @2.83 GHz processor representing a client machine.We evaluate and report the delay of different operations averagedover 1000 iterations. During our test, we used a 1 Gbps network linkand monitored the stability of the connection to avoid any possibleinterruption or fluctuations.
PASSAT Storage Cost and Latency.
The storage required to storea data in the baseline situation with no security and availabilityguarantee is equal to the size of the file. However, most of thecommon approaches recommend having at least 3 instances of adata for backup procedure [2]. If we assume having three backupsof a data as an enhanced-baseline that offers availability (similarbaseline were assumed in other studies, e.g.,[46]) PASSAT requiresexactly the same amount of storage to store data securely whileguaranteeing the confidentiality. For instance, [46] requires 6 timesof the file size storage to guarantee the confidentiality and avail-ability. The scheme proposed in [19], requires four times of the filesize storage in DEPSKY-A and over 2 times in DEPSKY-CA. PPSS[26] with the (2, 3)-secret sharing same as PASSAT utilizes threetimes of the file size storage.
Baseline Latency.
To measure the latency, we replicated the pro-cess of uploading and downloading files to and from each of thecloud providers individually and considered that as the baseline.This time does not include the authentication time to the cloudstorage service. Therefore, we consider our baseline as the mostoptimistic scenario which assumes that the user is already authen-ticated to the services. Figures 6 and 7 represent the average timeit takes to upload and download different file sizes into and fromeach of these cloud providers. As for the upload, as expected theminimum delay is related to the small files of size 10KB with anaverage of about 1.6 seconds. For larger files of size 200MB, thedelay is about 40 seconds. The download takes about 0.7 seconds forthe small size of 10KB and about 55 seconds for the large file size of200MB. We do not intend to compare different platforms with eachother, however, the difference between them is mainly related to theAPI implementation. For example, Google Drive uses a resumable download for files larger than 5MB and downloads the files chunkby chunk, which is perhaps reflected in the higher download timefrom Google Drive on large files compared to Dropbox and Box.
Block Secret-Sharing Latency.
We measured the time it takes tosecret-share and reconstruct each block of size 𝑑 -bit for 5 differentblock sizes (i.e., 𝑑 = 𝑡 , ≤ 𝑡 ≤ ). We computed the time it takesto secret-share files as the overhead of PASSAT over the baseline.We considered small files of size 10KB and 100KB, medium size filesof size 1MB, and large files of size 10MB. For each file, we considered .
70 1798 .
68 2159 .
22 3520 .
55 17867 .
29 42697 . .
95 1872 .
14 1924 .
16 3822 .
52 16325 .
56 40258 . .
14 1372 .
14 1535 .
65 3546 .
85 14877 .
00 39514 . T i m e i n M illi s e c o nd File SizeGoogle Drive BOX Dropbox
Figure 6: Time to store various files in major cloud providers .
53 331 .
53 1045 .
65 6586 .
65 41143 .
11 103906 . .
25 1385 .
40 1701 .
35 3294 .
30 22801 .
56 38125 . .
09 937 .
09 1408 .
14 2495 .
56 11419 .
00 23827 . T i m e i n M illi s e c o nd File SizeGoogle Drive BOX Dropbox
Figure 7: Time to retrieve files from major cloud providers 𝑑 = 𝑡 , ≤ 𝑡 ≤ ). We computed theexecution time averaged over 1000 iterations for each operation.As shown in Figure 8, overall the (2, 3)-XOR secret sharing has avery low latency (few nanoseconds) for various block sizes. File Secret-Sharing Latency.
As discussed in Sections 4, PASSATreads through the file in blocks of 𝑑 -bits and applies the (2, 3)-XORsecret sharing scheme to each block and then appends them to secretshare the file. The process time varies depending on the file sizeand the block size. To obtain the most efficient time for generatingthe shares and reconstructing the file, we tested PASSAT againstdifferent file sizes and using various 𝑑 -bits blocks sizes, aiming toobtain the most efficient block size. In this computation, we havenot optimized the code (i.e., the file is read sequentially 𝑑 -bit at atime and computation happens in one thread).Figure 9 demonstrates the time taken to generate the shares,which shows an increase as the files size increases. If we allow thesecret sharing to add a 10% overhead over the baseline system, wenotice that in the file sizes of ≤ < 𝑑 = offers the fastest secret-sharing time. It seems for block sizes thatare larger than 𝑑 = (i.e., in our test 4096, and 8192 bits) the .
00 4 .
00 6 .
00 7 .
00 9 .
00 12 . .
00 6 .
00 6 .
00 7 .
00 14 .
00 16 . .
00 6 .
00 7 .
00 10 .
00 14 .
00 18 . .
00 9 .
00 13 .
00 23 .
00 52 .
01 78 . T i m e i n M i c r o s e c o nd Block Size
Reconstruct Blocks s1 s2 Reconstruct Blocks s1 s3 Reconstruct Blocks s2 s3 Secret Share a Block
Figure 8: Time to secret-share each block for various sizes .
09 4 .
63 3 .
92 3 .
55 3 .
73 3 . .
52 24 .
09 16 .
82 13 .
53 14 .
25 14 . .
16 227 .
49 150 .
08 118 .
81 126 .
05 129 . , .
43 2 , .
96 1 , .
05 1 , .
75 1 , .
65 1 , . T i m e i n M illi s e c o nd Block Size10KB 100KB 1MB 100MB
Figure 9: Time to secret-share various files using varioussizes time of secret sharing increases. We relate this to the underlyingclient processor and memory architecture.Figure 10 shows the average time it takes to reconstruct the file.Note that usually a file is downloaded more frequently than it isuploaded (or updated). Also, the network downstream bandwidth istypically higher than the upstream bandwidth. Therefore, the timeit takes to recover the file is as of more importance compared to thetime it takes to generate the shares from the file. Figure 10 showsthat, as the size of the block increases the time it takes to reconstructthe file decreases, the best reconstruction performance happensfor the blocks of size 𝑑 = (slightly lower than 𝑑 = ). Thereconstruction overhead seems to be acceptable for files of varioussizes since the reconstruction only deals with computation on 2 outof 3 shares while during the secret sharing three shares should begenerated. Of course, the code optimization and parallelization canimprove the delay associated with each operation. File Splitting Latency.
As mentioned earlier PASSAT can splitlarge files before secret sharing (and merge them back after recon-struction). We developed a simple file splitting of textual file typesand computed the average time to split and merge the files. Usingthis code, splitting a 100MB file to 100 smaller files of size 1MB tookon average about 128 ms, and merging the 10 files of size 10MB tothe 100MB file took 112 ms. This result shows that splitting does not .
82 9 .
13 5 .
22 3 .
08 2 .
22 1 . .
98 10 .
73 6 .
30 3 .
85 2 .
93 2 . .
97 10 .
93 6 .
33 3 .
83 2 .
92 2 . T i m e i n M ili s e c o nd File Size: 100KBReconstruct s1 s2 Reconstruct s1 s3 Reconstruct s2 s3011223 256 512 1024 2048 4096 8192 .
70 0 .
90 0 .
50 0 .
31 0 .
23 0 . .
00 1 .
09 0 .
62 0 .
40 0 .
29 0 . .
01 1 .
08 0 .
62 0 .
39 0 .
30 0 . T i m e i n M ili s e c o nd File Size: 10KBReconstruct s1 s2 Reconstruct s1 s3 Reconstruct s2 s3050100150200250 256 512 1024 2048 4096 8192 .
84 92 .
24 53 .
38 31 .
49 22 .
69 16 . .
97 110 .
58 64 .
28 39 .
47 29 .
64 22 . .
83 112 .
20 64 .
26 39 .
36 29 .
83 22 . T i m e i n M ili s e c o nd File Size: 1MBReconstruct s1 s2 Reconstruct s1 s3 Reconstruct s2 s3 05001000150020002500 256 512 1024 2048 4096 8192 , .
57 934 .
28 534 .
53 320 .
73 236 .
18 170 . , .
21 1 , .
39 658 .
07 402 .
83 303 .
83 230 . , .
15 1 , .
89 651 .
09 403 .
75 304 .
31 232 . T i m e i n M ili s e c o nd File Size: 10MBReconstruct s1 s2 Reconstruct s1 s3 Reconstruct s2 s3
Figure 10: Time taken to reconstruct various file sizes with various block sizes from different shares impose a significant delay and file splitting before secret sharingcan be feasible to secret-share large files, given that multiple smallfiles can be secret-shared in parallel (as the operation on small filesare independent).
Other secret sharing approaches.
In this paper, we built oursystem using three major free storage providers, however, this ap-proach can be integrated with other cloud providers. We also chosea secret sharing scheme which uses simple XOR operation to con-struct and reconstruct shares. The modular design of PASSAT allowsthe use of other secret-sharing algorithms (e.g.,[30, 36, 38]). Sincethe secret-sharing component is independent of other modules (e.g.,cloud storage and password manager) replacing it with anotherscheme does not affect the protocol. Similarly, our fundamentalidea can work with any manager or storage.
Vendor lock-in.
Several works has discussed the cost of datamigration between cloud services and the Vendor lock-in problem[12, 19, 21]. PASSAT addresses this concern since it does not dependon a single provider. Also, any possible rate inflation by any of theproviders the data can be recovered and accessed from the two otherstorage providers. Hence, the migration cost can be completelyeliminated by leaving the costly storages. That is, in many of thecases PASSAT offers free of cost migration, and in cases where twoof the vendors increase their price, only one migration is required.
PASSAT as an online service.
Our current implementation ofPASSAT requires users to register with cloud providers and sharetheir credentials with the password manager. However, an efficientscenario is to implement PASSAT as a service to offer reliable stor-age functionality to users. Therefore, as a part of future work, weaim to deploy PASSAT as a service and study any possible chal-lenges (e.g., security of authentication to the PASSAT service, com-munication with storages, cost of deployment). Further researchcould also usefully expand PASSAT as a mobile application allowingusers to securely share their file from their smartphone. This appli-cation can also uses PASSAT web-service to perform file operation.
Trust on password manager.
We discussed how the access to-kens could be stored on the password manager, which requires truston the password manager. To reduce the trust on this component,we can secret-share the access tokens on multiple password man-agers. Other type of secure storeless password managers such asthe one proposed in [39] could also be used. This type of passwordmanager does not store the password, but reconstructs it throughan oblivious cryptographic protocol. Therefore, if PASSAT usesthis type of password manager, the tokens can be reconstructedon every session, without the need to store them. However, thisapproach is valid only if the storage provider allows the tokensto be generated by external entities (not by themselves, as is thecase currently with most providers). We should also mention thatinputting the (master) password is not necessary for each and everyoperation. The password can be entered for one session and bealid for a period of time. Similarly, the tokens can be stored byPASSAT for without interacting with the password manager.
Many of the previous researchers focused on availability of thedata on the storage. Some considered the Redundant Array of Inex-pensive Disks (RAID) as a data storage virtualization technologyto combine multiple hard disk components to guarantee data re-dundancy [23, 33, 34]. Depending on the required level of redun-dancy, they scatter the data over the drives. However, RAID onlyprovides sector redundancy dynamically across hard-drives andprotects against data loss by mirroring the driver to get a secureredundancy, and it still does not offer a solution to rectify securityand privacy concerns. Other studies used the secure erasure code[12, 15, 21, 32, 44] to enhance the availability of the data. Thesemethods only target the availability (not confidentiality). Thus, anunauthorized access to any disk can lead to data leakage.A variety of techniques are introduced to disperse data andimprove the availability, security, and privacy of data over the dis-tributed storages [12, 19, 21, 27, 28, 32, 35, 41, 44–46]. Approacheslike [35] assume that the user encrypts data prior to uploading tothe cloud and therefore leave the confidentiality up to the user toaddress. Many of these studies including [19, 32, 43] use a form ofencryption to ensure the confidentiality of the data. Apart from theheavy computational cost of encryption and decryption, they usesecret sharing to share the encryption keys, which adds anotherlevel of complication. Many of the proposed approaches including[21, 24, 26, 28, 35] require some sort of modification or code execu-tion at the server side, while PASSAT is transparent to the serverand requires no additional modification and changes in cloud logic.Similarly, [32] aimed to enhance the privacy of the stored data inthe distributed storage systems. They combined a decentralized era-sure code and threshold public key encryption scheme. Their cloudstorage system is not secure against a probabilistic polynomial timeattacker with a non-negligible advantage. Moreover, such a systemadds a significant overhead compared to our approach.HAIL [21] is another approach that ensures the availability andintegrity of data through distributed cryptographic systems. HAILutilizes Proofs of Retrievability (PORs) and relies on a single trustedverifier to verify the integrity of a retrieved file. The system doesnot use any secret key for the verifiability. HAIL offers the integrityand availability by aggregating cryptographic protocols and erasurecodes. However, HAIL requires server-side changes. More impor-tantly, it does not guarantee the confidentiality of the stored data.Several studies have been conducted to offer confidentiality, avail-ability, and integrity by combining different techniques [19, 43].Bessani et al. [19] proposed DepSky, which uses encryption and se-cret sharing techniques to store the data in different cloud services.DepSky encrypts the data using a random secret key. It divides thesecret key and then distributes block of the encrypted data and ashare of the key in each cloud server. However, what makes ourstudy different from [19] is that they followed the traditional ap-proach of encryption which requires a secure server to manage thekeys. Instead, PASSAT requires no server side changes and utilizesa password manager for authenticating to the cloud. Moreover,DepSky uses the approach proposed in [30], which makes the dataonly computationally secret rather than theoretically being secure. Unlike [19], we do not use any form of encryption. Apart fromthe extra workload that it may cause, our approach is obliging ifencryption is prohibited [1].Also, relevant to our work is the idea of password protected secretsharing (PPSS) generalized in [14]. PPSS is a protocol suggested toaddress the security and reliability issues in storing a secret data onuntrusted platforms. In this protocol, a user Alice 𝑈 has some secretinformation 𝑠𝑐 that she wants to store and protect, and be able tolater access on the basis of a single password 𝑝𝑤 from her clientmachine 𝐶 . Note that 𝑝𝑤 is password specific to the PPSS protocol.The system still requires an access token 𝑡𝑘 (stored on the client) toauthenticate a pair of 𝑈 and 𝐶 . In PPSS, 𝐶 uses 𝑡𝑘 ’s to communicatewith every cloud server 𝑆 , ..., 𝑆 𝑛 after which, each server 𝑆 𝑖 storessome information 𝑤 𝑖 associated with U ( 𝑤 𝑖 is a function of the secret 𝑠𝑐 , the password 𝑝𝑤 and server name 𝑆 𝑖 ). On the reconstructionphase, when 𝑈 needs to retrieve 𝑠𝑐 through 𝐶 , she performs areconstruction protocol by interacting with a subset of at least 𝑘 servers where the only input from 𝑈 is her password 𝑝𝑤 and 𝑡𝑘 ’s.An attacker breaking into 𝑘 − servers (e.g., either a maliciousinsider or an attacker who knows 𝑡𝑘 ) cannot gain any informationon 𝑠𝑐 other than by correctly guessing 𝑝𝑤 and running an on-lineattack with it. While PPSS [14] can address the availability andsecrecy concerns, unlike our approach, PPSS critically requiresserver-side changes and thus cannot be used readily with any ofthe existing storage service providers (thus presenting a majordeploymental hurdle). Same security properties apply to PASSAT.However, PASSAT (with standard password manager, like Lastpass)does not require server side changes, while in PPSS the server takespart in running the PPSS protocol. Also, PASSAT provides a higherefficiency since the XOR secret sharing used in PASSAT is muchfaster than the encryption, secret sharing, and PPSS protocol. In the paper, we presented PASSAT, a practical new paradigmthat enhances the confidentiality, integrity, and availability of thefiles stored in a public cloud. PASSAT attained these objectives byutilizing a fast and light-weight XOR secret sharing scheme andleveraging the power of publicly available cloud platforms in atransparent manner to essentially build a “cloud of clouds”. UsingXOR secret sharing, PASSAT generates three secret shares of theuser’s data file, whereby learning just one of these shares revealsno meaningful information about the file and at least two secretsare required to build the original file. Such an approach enhancesthe availability of data in case one of the cloud providers becomesinaccessible (or temporarily congested). PASSAT also guaranteesthe integrity of the data, as any modification of at most two ofthe secret shares will impact the reconstruction of the file (thereconstructed file will be garbage). PASSAT can provide all theseproperties, while offering the user experience similar to that ofpassword authentication as users can be given access to their cloud-stored files with just a single master password, which locks theaccess tokens used to authenticate to each of the cloud serviceproviders. Our design, implementation, and evaluation of PASSATshow that it is efficient enough to be readily employed by the usersto improve the confidentiality, availability, and integrity of theirsensitive data.
EFERENCES
Proceedings of the 1st ACM symposium onCloud computing . ACM, 229–240.[13] JSebastian Anthony. 2014. How Dropbox knows you’re a dirty pirate, and whyyou shouldn’t use cloud storage to share copyrighted files. https://goo.gl/GUPqqS[14] Ali Bagherzandi, Stanislaw Jarecki, Nitesh Saxena, and Yanbin Lu. 2011. Password-protected secret sharing. In . ACM, 433–444.[15] Cristina Băsescu, Christian Cachin, Ittay Eyal, Robert Haas, Alessandro Sorniotti,Marko Vukolić, and Ido Zachevsky. 2012. Robust data sharing with key-valuestores. In
Dependable Systems and Networks (DSN), 2012 42nd Annual IEEE/IFIPInternational Conference on . IEEE, 1–12.[16] Amos Beimel. 2011. Secret-Sharing Schemes: A Survey.
IWCC
Proceedings of the 14thACM conference on Computer and communications security . ACM, 172–184.[18] Josh Benaloh and Jerry Leichter. 1990. Generalized secret sharing and monotonefunctions. In
Proceedings on Advances in cryptology . Springer-Verlag New York,Inc., 27–35.[19] Alysson Bessani, Miguel Correia, Bruno Quaresma, Fernando André, and PauloSousa. 2013. DepSky: dependable and secure storage in a cloud-of-clouds.
ACMTransactions on Storage (TOS)
9, 4 (2013), 12.[20] George Robert Blakley et al. 1979. Safeguarding cryptographic keys. In
Proceed-ings of the national computer conference , Vol. 48. 313–317.[21] Kevin D Bowers, Ari Juels, and Alina Oprea. 2009. HAIL: A high-availabilityand integrity layer for cloud storage. In . ACM.[22] JAN CURN. 2013. A Cautionary Tale: How a Bug in Dropbox PermanentlyDeleted 8,000 of My Photos. https://bit.ly/2OEYdPT[23] Garth Alan Gibson. 1992. Redundant disk arrays: Reliable, parallel secondarystorage. (1992).[24] James Hendricks, Gregory R Ganger, and Michael K Reiter. 2007. Low-overheadbyzantine fault-tolerant storage. In
ACM SIGOPS Operating Systems Review ,Vol. 41. ACM, 73–86.[25] Mitsuru Ito, Akira Saito, and Takao Nishizeki. 1989. Secret sharing schemerealizing general access structure.
Electronics and Communications in Japan
72, 9(1989), 56–64.[26] Stanislaw Jarecki, Aggelos Kiayias, and Hugo Krawczyk. 2014. Round-optimalpassword-protected secret sharing and T-PAKE in the password-only model.In
International Conference on the Theory and Application of Cryptology andInformation Security . Springer, 233–253.[27] Philipp Junghanns, Benjamin Fabian, and Tatiana Ermakova. 2016. Engineeringof secure multi-cloud storage.
Computers in Industry
83 (2016), 108–120.[28] Seny Kamara, Charalampos Papamanthou, and Tom Roeder. 2011. Cs2: A search-able cryptographic cloud storage system.
Microsoft Research, TechReport MSR-TR-2011-58 (2011).[29] Jeremy Kirk. 2013. Dropbox takes a peek at files. But it’s totally nothing, saysDropbox. https://bit.ly/2WNcsFl[30] Hugo Krawczyk. 1993. Secret Sharing Made Short.. In
Crypto , Vol. 93. Springer,136–146.[31] Jun Kurihara, Shinsaku Kiyomoto, Kazuhide Fukushima, and Toshiaki Tanaka.2008. A new (k, n)-threshold secret sharing scheme and its extension.
InformationSecurity (2008), 455–470.[32] Hsiao-Ying Lin and Wen-Guey Tzeng. 2010. A secure decentralized erasure codefor distributed networked storage.
IEEE transactions on Parallel and DistributedSystems
21, 11 (2010), 1586–1594.[33] David A Patterson, Peter Chen, Garth Gibson, and Randy H Katz. 1989. Introduc-tion to redundant arrays of inexpensive disks (RAID). In
COMPCON Spring’89.Thirty-Fourth IEEE Computer Society International Conference: Intellectual Lever-age, Digest of Papers.
IEEE, 112–117.[34] David A Patterson, Garth Gibson, and Randy H Katz. 1988.
A case for redundantarrays of inexpensive disks (RAID) . Vol. 17. ACM. [35] Raluca Ada Popa, Jacob R Lorch, David Molnar, Helen J Wang, and Li Zhuang.2011. Enabling Security in Cloud Storage SLAs with CloudProof.. In
USENIXAnnual Technical Conference , Vol. 242.[36] Michael O Rabin. 1989. Efficient dispersal of information for security, loadbalancing, and fault tolerance.
Journal of the ACM (JACM)
36, 2 (1989), 335–348.[37] Jason K. Resch and James S. Plank. 2011. AONT-RS: Blending Security andPerformance in Dispersed Storage Systems. In .[38] Adi Shamir. 1979. How to share a secret.
Commun. ACM
22, 11 (1979), 612–613.[39] Maliheh Shirvanian, Stanislaw Jareckiy, Hugo Krawczykz, and Nitesh Saxena.2017. SPHINX: A password store that perfectly hides passwords from itself. In
Distributed Computing Systems (ICDCS) .[40] Roman Shor, Gala Yadgar, Wentao Huang, Eitan Yaakobi, and Jehoshua Bruck.2018. How to Best Share a Big Secret. In . ACM, 76–88.[41] Alexander Shraer, Christian Cachin, Asaf Cidon, Idit Keidar, Yan Michalevsky, andDani Shaket. 2010. Venus: Verification for untrusted cloud storage. In
Workshopon Cloud computing security . ACM.[42] Daniel Slamanig and Christian Hanser. 2012. On cloud storage and the cloud ofclouds approach. In
Internet Technology And Secured Transactions, 2012 Interna-tional Conference for . IEEE.[43] Josef Spillner, Gerd Bombach, Steffen Matthischke, Johannes Muller, RicoTzschichholz, and Alexander Schill. 2011. Information dispersion over redundantarrays of optimal cloud storage for desktop users. In
Utility and Cloud Computing(UCC), 4th IEEE International Conference on . IEEE.[44] Emil Stefanov, Marten van Dijk, Ari Juels, and Alina Oprea. 2012. Iris: A scalablecloud file system with efficient integrity checks. In . ACM.[45] Zooko Wilcox-O’Hearn and Brian Warner. 2008. Tahoe: the least-authorityfilesystem. In .ACM, 21–26.[46] Jay J Wylie, Michael W Bigrigg, John D Strunk, Gregory R Ganger, Han Kiliccote,and Pradeep K Khosla. 2000. Survivable information storage systems.
Computer
33, 8 (2000), 61–68.
Algorithm 1
PASSAT Secret Sharing function Split( 𝑓 𝑖𝑙𝑒 𝑓 ) if 𝑠𝑖𝑧𝑒 ( 𝑓 𝑖𝑙𝑒 ) > 𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑 𝑡 then { 𝑓 . . ., 𝑓 𝑛 } ← 𝑓 / 𝑡 𝑡𝑎𝑔 𝑡 𝑖 ↦→ 𝑓 𝑖 | 𝑖 = , , . . .,𝑛 return ( 𝑓 𝑖 ,𝑡 𝑖 ) = 𝑑 𝑖 end function function Secret Share( 𝑑 ) 𝑠 ← 𝑑 ,𝑠 || . . . || 𝑠 𝑛𝑝 − ← 𝑠 for 𝑖 ← to 𝑘 − do for 𝑗 ← to 𝑛 𝑝 − do 𝑟 𝑗𝑖 ← 𝐺𝐸𝑁 ({ , } 𝑑 ) end for end for (discard 𝑟 𝑛𝑝 - 1) for 𝑖 ← to 𝑛 − do for 𝑗 ← to 𝑛 𝑝 − do 𝑆 ( 𝑖,𝑗 ) ← (⊕ 𝑘 − ℎ = 𝑟 ℎℎ.𝑖 + 𝑗 ) ⊕ 𝑠 𝑗 − 𝑖 end for 𝑆 𝑖 ← 𝑆 ( 𝑖, ) || . . . || 𝑆 ( 𝑖,𝑛𝑝 − ) end for return { 𝑆 . . .,𝑆 𝑛 − } end function function auth 𝐿𝑎𝑠𝑡𝑝𝑎𝑠𝑠.𝑟𝑒𝑡𝑟𝑖𝑣𝑒 { 𝑡𝑘 ,𝑡𝑘 ,𝑡𝑘 } for 𝑖 = to 𝑛 do 𝐶𝑙𝑜𝑢𝑑 𝑐 𝑖 ← 𝑆 𝑖 end for end function Algorithm 2
PASSAT Reconstruction function auth 𝐿𝑎𝑠𝑡𝑝𝑎𝑠𝑠.𝑟𝑒𝑡𝑟𝑖𝑣𝑒 { 𝑡𝑘 ,𝑡𝑘 ,𝑡𝑘 } for 𝑖 = to 𝑛 do 𝑆 𝑖 ← 𝑐 𝑖 end for end function function Secret Reconstruct( 𝑑 ) for 𝑖 ← to 𝑘 − do 𝑆 ( 𝑆𝑡𝑖 , ) || . . . || 𝑆 ( 𝑖,𝑛𝑝 − )← 𝑆𝑡𝑖 end for 𝑆 ← ( 𝑆 ( 𝑆𝑡 , ) , . . .,𝑆 ( 𝑆𝑡 ,𝑛𝑝 − ) ,. . .,𝑆 ( 𝑆𝑡𝑘 − , ) , . . .,𝑆 ( 𝑆𝑡𝑘 − ,𝑛𝑝 − ) ) 𝑇 𝑀 ← 𝑀𝐴𝑇 ( 𝑡 , . . .,𝑡 𝑘 − ) (( 𝑠 , . . .,𝑠 𝑛𝑝 − )) 𝑇 ← 𝑀.𝑆 𝑠 ← 𝑠 || . . . || 𝑠 𝑛𝑝 − return 𝑠 end function function merge( 𝑠𝑒𝑐𝑟𝑒𝑡 𝑠 ) if 𝑡 𝑛 ∃ 𝑠 then for 𝑠,𝑡 𝑛 do 𝑓 ← 𝐶𝑜𝑛𝑐𝑎𝑡𝑒𝑛𝑎𝑡𝑒 ( 𝑠 𝑡 , . . .,𝑠 𝑡𝑛 ) return 𝑓 end for23: