Encrypted Multi-map that Hides Query, Access, and Volume Patterns

Abstract

We present an encrypted multi-map, a fundamental data structure underlying searchable encryption/structured encryption. Our protocol supports updates and is designed for applications demanding very strong data security. Not only it hides the information about queries and data, but also the query, access, and volume patterns. Our protocol utilizes a position-based ORAM and an encrypted dictionary. We provide two instantiations of the protocol, along with their operation-type-revealing variants, all using PathORAM but with different encrypted dictionary instantiations (AVL tree or BSkiplist). Their efficiency has been evaluated through both asymptotic and concrete complexity analysis, outperforming prior work while achieving the same level of strong security. We have implemented our instantiations and evaluated their performance on two real-world email databases (Enron and Lucene). We also discuss the strengths and limitations of our construction, including its resizability, and highlight that optimized solutions, even with heavy network utilization, may become practical as network speed improves.

T. Tang—This work was conducted while the author was at Georgia Institute of Technology.

Appendices

A Structured Encryption ($\textsf{STE}$) Definitions

Correctness. We define the decryption correctness and ${\textsf{Access}}$’s operational correctness as follows. For all $\kappa \in {{\mathbb N}}$, all $z \in \{0,1\}^*$, all data structure (with data) $\textsf{ds}\subseteq \mathbb {L}\times \mathbb {V}$ with functionality $\mathcal {F}$, we say that $\textsf{EDS}$ instantiates $\textsf{ds}$ if and only if for all $(K, \textsf{EDS})$ output by ${\textsf{Setup}}(1^\kappa , z, \textsf{ds})$, $\textsf{Dec}(K, \textsf{EDS}) = \textsf{ds}$; let $\textsf{ds}_1 \leftarrow \textsf{ds}$ and $\textsf{EDS}_1 \leftarrow \textsf{EDS}$, after applying an arbitrary polynomial-size sequence of operations $\{(\textsf{op}_i, \ell _i, v_i)\}_{i \in [q]}$ to $\textsf{EDS}_1$, where $\textsf{op}_i \in \mathbb {O}, \ell _i \in \mathbb {L}, v_i \in \mathbb {V}$; for all $i \in [q]$, $(v_{i+1}, \textsf{EDS}_{i + 1}) \leftarrow [{\textsf{Access}}_{\textbf{C}}(K, \textsf{op}_i, \ell _i, v_i), {\textsf{Access}}_{\textbf{S}}(\textsf{EDS}_i)]$, we require $v_{i + 1} = v_{i + 1}'$ and $\textsf{Dec}(K, \textsf{EDS}_{i + 1}) = \textsf{ds}_{i + 1}'$, where $(v_{i + 1}', \textsf{ds}_{i + 1}')$ $\leftarrow$ $\mathcal {F}(\textsf{ds}_i, \textsf{op}_i, \ell _i, v_i)$.

1.1 A.1 STE Security Definition

Definition A1

(Adaptive Security for $\textsf{STE}$). Given label space $\mathbb {L}$, value space $\mathbb {V}$, and operation type space $\mathbb {O}$, let $\varPi$ be a $\textsf{STE}$ protocol with functionality $\mathcal {F}$. Let $\mathcal {L}_{\varPi } = (\mathcal {L}_{{\textsf{Setup}}}, \mathcal {L}_{{\textsf{Access}}})$ be the leakage profile describing leakage of $\varPi$’s algorithms. Let $\kappa \in {{\mathbb N}}$ be the security parameter. Consider the probabilistic experiments defined in Fig. 5.

Fig. 5.

Experiments for Defining $\textsf{STE}$ Adaptive Security.

We say that $\varPi$ is adaptively $\mathcal {L}_{\varPi }$-secure if for all $z \in \{0,1\}^*$, there exists a PPT simulator $\mathcal {S}$ such that for all PPT adversaries $\mathcal {A}$, all q which is a polynomial (in $\kappa$), the following is negligible (in $\kappa$):

$$ \Big |{\Pr \left[ \,{\textbf{Real} _{\varPi , \mathcal {A}, q}(1^{\kappa }, z) = 1}\,\right] } - {\Pr \left[ \,{\textbf{Ideal} _{\varPi , \mathcal {A}, \mathcal {S}, \mathcal {F}, q}(1^{\kappa }, z) = 1}\,\right] } \Big |. $$

B Extended Functionality for $\textsf{EDX}$

Definition B1

($\widetilde{\mathcal {F}}_{\mathsf {{DX}}}$). Let label space $\mathbb {L}= \{0,1\}^*$ and value space $\mathbb {V}= \{0,1\}^*$, where $\textsf{dx}\subseteq \mathbb {L}\times \mathbb {V}$, $\textsf{op}\in \{\textsf{Get}, \textsf{Put}, \textsf{Remove}, \textsf{GetUp}\}$, $\widetilde{\mathcal {F}}_{\mathsf {{DX}}}(\textsf{dx}, \textsf{op}, \ell , v)$: where data structure $\textsf{dx}$ is stored in the state, $\textsf{op}\in \mathbb {O}$, $\ell \in \mathbb {L}$, and $v \in \mathbb {V}$,

• 1. If $\textsf{op}\in \{\textsf{Get}, \textsf{Put}, \textsf{Remove}\}$, define the same as in Definition 31.

• 2. If $\textsf{op}= \textsf{GetUp}$, parse v as $v_1 \Vert v_2$,

  • if $\ell$ is in $\textsf{dx}$ then $v^* \leftarrow \textsf{dx}[\ell ]$; parse $\textsf{dx}[\ell ]$ as $v_1'\Vert v_2'$; $\textsf{dx}[\ell ] \leftarrow v_1' \Vert v_2$;

  • otherwise:

    • if $v_1 \ne \bot$ then $\textsf{dx}[\ell ] \leftarrow v$ and $v^* \leftarrow v$;

      otherwise $v^* \leftarrow \bot$.

• 3. Output $(v^*, \textsf{dx})$.

C Algorithms for Auxiliary Class $\textsf {BidStack}$

Fig. 6.

Algorithms for Auxiliary Class $\textsf {BidStack}$.

In Fig. 6, we include the algorithms of the auxiliary class $\textsf {BidStack}$.

D Implementations and Experiments

Since our instantiations achieve the volume-hiding property through padding each tuple to the largest size, this specific keyword space captures the worst scenario for evaluation. As in the complexity analysis, we store document identifiers in each PathORAM block using the cheaper storage representation of the two: either a list of $l$ document identifiers where each is a 32-bit integer or a bitvector of N-bits where all 1’s indicate the matched document identifiers in the database. Still, we show that our instantiations are practical in this setting. Our experimental results were generated on a commodity laptop with 12-core Intel(R) Core i7-8750H CPU @ 2.20GHz, 16GB RAM, and 360GB SSD, running Ubuntu 20.04.

In all $\textsf{EMM}$ instantiations, we use the parameters in Fig. 4f, where N denotes the total number of documents, k denotes the maximum keyword length in bytes, and l denotes the maximum tuple length, namely, the maximum number of emails associated with every single keyword. We also fix the growth factor to 1.5. All AVL-tree-based and BSkiplist-based instantiations took less than 30 minutes to set up either Enron or Lucene. Same to the concrete complexity analysis, in our experiments, we assume $80\%$ operations are $\textsf{Get}$, $10\%$ are $\textsf{Put}$, and the rest $10\%$ are $\textsf{Remove}$. We generated the results by running 1000 operations on each dataset, performing $\textsf{Get}$ and $\textsf{Remove}$ operations on keywords and associated document identifiers selected randomly from the corresponding dataset. We also ensure that $\textsf{Remove}$ is performed first and $\textsf{Get}$ after, canceling each other out so that after 1000 operations, the dataset stays the same as the setup one. The average computational time for each operation among all instantiations is below 300 ms. For the more concerned communicational overhead, we simulated the communicational time under network condition with 100 mbps for either uploading or downloading and 30 ms in round latency. Table 1 shows that the communicational overhead is still reasonable for practice among all instantiations. Although the bandwidth costs are comparable between the AVL-tree-based instantiations and BSkiplist-based ones, the round complexity contributes significantly to the query latency. Our experiments show that the BSkiplist-based instantiations and the operation-revealing variants are preferable.

Both Enron and Lucene are commonly used as the target databases to demonstrate the effectiveness of the leakage-abuse attacks. Notably, the email databases are vulnerable to file-injection attacks as everyone can send emails to the target client. Thus evaluating performance on the above two databases carries practical meaning to demonstrate our instantiations’ effectiveness minimizing all common SSE/STE leakage patterns while being sufficiently efficient for practice. Though our instantiations cost more bandwidth and rounds than the “leaky” solutions for strong security, we show that they are practically promising in some applications (e.g., email databases).