SecurePass@K: Intrusion-Tolerant Cloud Storage

• SecurePass@K is a client-side, intrusion-tolerant multi-cloud storage system that uses XOR-based secret sharing to ensure information-theoretic confidentiality.
• It integrates a password vault with off-the-shelf cloud services, enabling secure retrieval and storage of secret shares with minimal performance overhead.
• The architecture guarantees file integrity and availability by allowing reconstruction from a threshold of shares even if one cloud is compromised.

SecurePass@K is a client-side, intrusion-tolerant storage system that enables secure and efficient file storage on multiple public cloud platforms, providing confidentiality, integrity, and availability guarantees through a combination of information-theoretic XOR-based secret sharing and single-password authentication. The architecture, as instantiated by the PASSAT system (Satvat et al., 2021), is entirely transparent to cloud servers, requiring no provider cooperation or server-side modifications and leveraging off-the-shelf password managers to protect per-cloud authentication credentials under a single master password.

1. System Architecture and Workflow

SecurePass@K comprises three main components: a client application (PASSAT), a password vault (e.g., LastPass), and multiple cloud storage platforms. The client application integrates a Secret-Sharing Engine ("SecretGen") that implements XOR-based threshold secret sharing, and middleware that interfaces with both the password manager for credential retrieval and cloud platforms for file storage and retrieval. An optional Splitter/Merger module divides large files into manageable chunks.

The password vault securely stores OAuth or platform-specific access tokens for each cloud service, encrypted under the user’s master password. Cloud storage platforms such as Google Drive, Box, and Dropbox each hold a secret share of every protected file.

Workflow Phases:

• Upload ("Store"):

1. User invokes PASSAT, selects file $F$, and provides master password $pw$.
2. Middleware authenticates to the password vault with $pw$ and retrieves cloud-specific access tokens $\{tk_1,\dots,tk_n\}$.
3. Optionally splitting $F$ into chunks, SecretGen generates $(k,n)$-XOR shares for every chunk or block.
4. Middleware authenticates to each cloud using $tk_i$ and uploads share $S_i$ to cloud $S_i$.

• Download ("Retrieve"):

1. PASSAT is launched and $pw$ is entered.
2. Tokens $\{tk_1,\dots,tk_n\}$ are fetched from the vault.
3. Middleware retrieves any $k$ of $n$ shares from the corresponding cloud platforms.
4. SecretGen reconstructs $F$ from these shares, reassembling any split chunks.

2. XOR-Based Secret Sharing Scheme

PASSAT implements the XOR-based $(k,n)$ threshold secret sharing scheme of Kurihara et al., providing information-theoretic security and high computational efficiency.

• Notation:
  • Given a file block $F \in \{0,1\}^{d\cdot(n_p-1)}$, partitioned as $F = (s_0 \Vert s_1\Vert \cdots \Vert s_{n_p-2})$, $n_p$ a prime $\geq n$.
  • $n$ shares $S_1,\dots,S_n$ are generated, each length $d\cdot(n_p-1)$.
  • Random masks $r^h \in \{0,1\}^d$, $h\in\{0,\dots,k-2\}$.
• Share Generation:

$$S_i[j] = \left( \bigoplus_{h=0}^{k-2} r^h_{[(i + h \cdot j) \bmod n_p]} \right) \oplus s_j$$

In the $(2,3)$ instantiation standard in PASSAT, with $n_p = 3$ and blocks $F_1, F_2$: - Select random $R_1, R_2$, - $S_1 = (R_1 \Vert R_2)$, - $S_2 = (R_1 \oplus F_1 \Vert R_2)$, - $S_3 = (R_1 \Vert R_2 \oplus F_2)$.

Any single share is independent of $F$; any pair suffices to reconstruct $F$ via XOR.

• Reconstruction: Given any $k$ of $n$ shares $S_{i_1}, \ldots, S_{i_k}$, $F$ is recovered by inverting the XOR pattern:

$\bigoplus_{i\in I} S_i = F$

(up to a fixed, invertible linear transformation defined by the scheme).

• Role of $(k,n)$: For $k=2$, $n=3$, SecurePass@K achieves information-theoretic confidentiality (any $t < k$ shares reveal no information about $F$) and tolerates up to $n-k$ unavailable or compromised clouds, constituting a balance between confidentiality and availability.

3. Master-Password-Based Authentication Mechanism

All per-cloud OAuth tokens $\{tk_1, \dots, tk_n\}$ are protected within a standard password vault $M$, encrypted using a symmetric key derived from the master password $pw$ via PBKDF2 or Argon2, and symmetrically encrypted (typically with AES-GCM). This configuration ensures that the user only enters $pw$ into the client, never typing individual cloud credentials into PASSAT.

Authentication Protocol per Platform $i$:

1. PASSAT requests the access token $tk_i$ from $M$, supplying $pw$.
2. The vault decrypts the token and returns $tk_i$ to PASSAT.
3. PASSAT uses $tk_i$ in an OAuth Bearer header to authenticate to cloud $S_i$.
4. Cloud authorizes upload/download operations.

No further cryptographic transformations are applied to the file shares beyond XOR secret-sharing. Token security is inherited from the vault’s encryption, and its rate-limited unlocking mechanism impedes offline password-guessing.

4. Security Properties and Adversarial Model

SecurePass@K's design targets three main security goals:

• Confidentiality: Any coalition of fewer than $k$ clouds obtains no information about $F$ (information-theoretic, by XOR sharing).
• Integrity: Any modification of a single share in a set of $k$ shares required for reconstruction renders at least one subblock unrecoverable, yielding a corrupted or random-looking output.
• Intrusion Tolerance: The system tolerates up to $k-1$ malicious or unavailable clouds and maintains single-password sign-on.

Adversary Model:

• May control up to $k-1$ clouds, obtaining stored shares.
• May acquire the encrypted password vault $M$ but must guess $pw$ to obtain tokens; password guessing is rate-limited by $M$ and by cloud API policies.

Security Arguments:

• Confidentiality: The joint distribution of any $t < k$ shares is statistically independent of $F$, ensuring perfect secrecy for sub-threshold coalitions.
• Integrity: Altering any one share for reconstruction causes XOR cancellation failure, producing garbage output. Detection is possible via hash validation or evident randomness.
• Vault Attack: Even if an encrypted token blob is stolen, $pw$ must be guessed (rate-limited). Obtaining $tk_i$ via $pw$ only allows cloud impersonation; reconstructing $F$ also requires $k$ shares.

5. Empirical Performance and Resource Utilization

Experimental Environment:

• Client: 8 GB RAM, quad-core 2.8 GHz CPU, Windows 64-bit, 1 Gbps LAN.
• Clouds: Google Drive, Box, Dropbox, via Python SDKs.
• File sizes: 10 KB – 200 MB; share block sizes $d = 2^t$ bits ($t=8\dots 13$).

Measured Quantities:

• Baseline upload/download times per provider (no sharing).
• Secret-sharing CPU time per block, total share/reconstruction time.
• Total end-to-end latency: secret-share/reconstruct + $3\times$(upload/download).

Key Results:

• Baseline upload time: 10 KB $\approx$ 1.6 s; 200 MB $\approx$ 40 s.
• Baseline download: 10 KB $\approx$ 0.7 s; 200 MB $\approx$ 55 s.
• XOR share/generation per block: single-digit nanoseconds up to $d = 8$ KB.
• Best share time for $d=2$ KB; best reconstruction time for $d=8$ KB.
• Overhead vs. baseline: $<$5% for files $\leq 1$ MB; 10–15% for 10 MB files.
• Splitting 100 MB file into 1 MB pieces adds $\sim0.13$ s—negligible compared to network latency.

File Size	Upload Overhead	Download Overhead
$\leq$ 1 MB	$<$5%	$<$5%
10 MB	10–15%	modest
200 MB	network-bound	network-bound

6. Comparison to Related Systems

SecurePass@K/PASSAT contrasts with both baseline and prior defenses for multi-cloud storage confidentiality and availability.

• Baseline (no protection): No confidentiality/integrity, $1\times$ storage overhead.
• Enhanced Baseline (encryption + replication): Confidentiality, higher CPU cost, tolerance limited to single-cloud failure.
• DepSky: Requires server changes, uses AES and secret-shared keys, $4\times$ storage, increased computation.
• PPSS: Password-protected secret sharing but dependent on custom server-side password protocol logic.
• HAIL: Provides only integrity and availability with server-side changes, no confidentiality.

Distinct Features of SecurePass@K/PASSAT:

• Server Transparency: Entirely client-side, with no modifications on cloud providers.
• Single-Password SSO: All tokens are unlocked via a single master password in an off-the-shelf vault.
• Efficiency: XOR sharing imposes less than 5% additional overhead relative to direct uploads for typical file sizes.
• Intrusion Tolerance: With $k=2, n=3$, up to any single cloud can be compromised without file exposure or modification.

7. Summary and Significance

SecurePass@K, as realized in the PASSAT framework, tightly integrates an ultra-fast XOR secret-sharing scheme with standard password-vault-based token protection to provide intrusion-tolerant, server-transparent multi-cloud storage hardening. The system delivers information-theoretic confidentiality, robust file integrity, and single-password usability for a practical spectrum of file sizes, all maintained with minimal performance overhead and no dependency on cloud provider modifications. This architecture immediately strengthens the security posture of users’ existing cloud storage accounts against adversaries capable of partial infrastructure compromise, while preserving the prevailing user and provider workflows (Satvat et al., 2021).