OblivShare: Towards Privacy-Preserving File Sharing with Oblivious Expiration Control

Abstract

People have personal and/or business need to share private and confidential documents; however, often at the expense of privacy. Privacy aware users demand that their data is secure during the entire life cycle, and not residing in clouds indefinitely. A trending feature in industry is to set download constraints of shared files - a file can be downloaded for a restricted number of times and/or within a limited time framework. Metadata privacy becomes concerning with web services and applications providing such additional level of security control but not hiding the metadata. There is no prior research focusing on privacy-preserving expiration control, hence we propose OblivShare, a privacy-preserving file sharing scheme to proactively fill the gap. The scheme is based on ORAM for secure computation that 1) supports file expiration at users’ control, 2) hides expiration metadata from the server, 3) server is fully oblivious of file access pattern and expiration state of a file. We demonstrate that our protocol has a complexity poly-logarithmic to the number of files while achieving privacy of metadata.

A METAL’s Synchronised Inside-Outside ORAM Trees

1.1 A.1 Secret-Shared Doubly Oblivious Transfer

Let N be an array of the blocks in the stash and the 3h blocks on path p:

• 1. The two servers inside S2PC, generate n keys ${k_1,\ldots ,k_n}$ such that S1 receives as output all these keys, and S2 receives only $k_i$. $n = |stash| + 3h + 1$.

• 2. For each $j \in {1,\ldots ,n}$, S1 uses $k_j$ to encrypt 0 and $m_j$ to obtain cipher-texts $z_j$ and $c_j$ respectively. S1 shuffles all the $(z_j, c_j)$ pairs and sends them to S2.

• 3. S2 uses $k_i$ to decrypt the first cipher-text of each pair: only one $z_j$, will decrypt to 0. It then decrypts the corresponding $c_j$ and hence obtain $m_i$.

1.2 A.2 Distributed Permutation

Recall that Circuit ORAM selects two paths during eviction, hence we need to track the movement of blocks in the stash and on the two paths, which has $|stash| = 6h - 3$ blocks.

Before each eviction, OblivShare appends a number tracker from 1 to $|stash| = 6h - 3$ to each block on the stash and two paths in ExpCtrlORAM inside S2PC. After the ExpCtrlORAM’s stash eviction, the protocol extracts the trackers and construct an array of the numbers. Note that some numbers no longer exist as the attaching blocks are removed during the eviction. In order to generate a permeation of the same $|stash| = 6h - 3$ elements, OblivShare searches for the missing trackers using a linear scan and fill in the empty slots with unused numbers.

Below, we present how the two servers in secure computation put a block into the DataORAM’s stash before eviction:

• 1. The S2PC places the following in an array: the blocks in the stash, the block read, and the block to write, which has $(|stash|+2)$ blocks.

• 2. The S2PC finds that the k-th block of the stash is vacant, then generates a permutation $\sigma ^{read}$ or $\sigma ^{write}$, which exchanges the k-th block with the read block for $\sigma ^{read}$ or the block to write for $\sigma ^{write}$. As a result, the correct block is inserted into the stash (i.e. the first |stash| blocks of the permuted array).

• 3. The S2PC secret shares the permutation ($\sigma ^{read}$ or $\sigma ^{write}$) into two permutations $\sigma ^1$ and $\sigma ^2$, when $\sigma ^2 = \sigma \circ (\sigma ^1)^{-1}$. $\circ$ denotes composition of permutation and $\sigma \circ (\sigma )^{-1}$ is the identity permutation.

• 4. S1 re-randomise the blocks, apply the permutations $\sigma ^1$, and sends the permuted blocks to S2.

• 5. S2 re-randomise the blocks received, apply the permutations $\sigma ^2$, and sends the permuted blocks back to S1.

• 6. S1 stores the permuted blocks in the corresponding location in DataORAM.