Highly distributed and privacy-preserving queries on personal data management systems

Abstract

Personal data management system (PDMS) solutions are flourishing, boosted by smart disclosure initiatives and new regulations. PDMSs allow users to easily store and manage data directly generated by their devices or resulting from their (digital) interactions. Users can then leverage the power of their PDMS to benefit from their personal data, for their own good and in the interest of the community. The PDMS paradigm thus brings exciting perspectives by unlocking novel usages, but also raises security issues. An effective approach, considered in several recent works, is to let the user data distributed on personal platforms, secured locally using hardware and/or software security mechanisms. This paper goes beyond the local security issues and addresses the important question of securely querying this massively distributed personal data. To this end, we propose DISPERS, a fully distributed PDMS peer-to-peer architecture. DISPERS allows users to securely and efficiently share and query their personal data, even in the presence of malicious nodes. We consider three increasingly powerful threat models and derive, for each, a security requirement that must be fulfilled to reach a lower-bound in terms of sensitive data leakage: (1) hidden communications, (2) random dispersion of data and (3) collaborative proofs. These requirements are incremental and, respectively, resist spied, leaking or corrupted nodes. We show that the expected security level can be guaranteed with near certainty and validate experimentally the efficiency of the proposed protocols, allowing for adjustable trade-off between the security level and its cost.

Appendices

Background on cryptography

Symmetric encryption is computationally efficient but requires a symmetric encryption key $k_{sym}$ known beforehand by both parties. On the contrary, asymmetric encryption is a demanding operation that relies on a pair of keys: the private key, $k_{priv}$, and its matching public key, $k_{pub}$. To avoid man-in-the-middle attacks, $k_{pub}$ must be certified. Hybrid encryption uses asymmetric encryption to securely exchange a symmetric encryption key and combines the advantages of both encryption schemes. To ensure forward secrecy [43], a new symmetric key is used for each communication session. The widely used TLS protocol is based on hybrid encryption and provides also integrity, and authenticity of the communicating parties.

A cryptographic hash function [43], referred as $\mathtt {hash}()$, is a one-way function that maps a data of arbitrary size to a fixed size bit string (e.g., 256 bits), is resistant to collision and provides a uniform distribution of its outputs.

A digital signature [43] can be used to prove that a data d was produced by an entity E (authentication) and has not been altered (integrity). A signature contains the encryption of $\mathtt {hash}(d)$ using ${ k_{priv} }_E$ and the certificate of ${ k_{pub} }_E$, $cert_E$. Anyone can check a signature by checking the certificate, decrypting the encrypted hash, and finally comparing the result with $\mathtt {hash}(d)$ (recomputed by the verifier).

Shamir’s Secret Sharing Scheme (SSSS) [63] consists in dividing some data d into n shares $d_1, \dots , d_n$ in such a way that: (i) knowledge of any t ($t\le n$) or more shares makes d easily computable; but (ii) knowledge of any $t - 1$ or fewer shares leaves d protected (not even providing any information about it). t is called the threshold value (see Sect. 8) and is set to resist to $n - t$ shareholders failures. The low, polynomial complexity of SSSS (i.e., Lagrange interpolation) for both secret decomposition and reconstruction, makes it an ideal solution for a fully distributed system like DISPERS in which any PDMS node has to securely store its profile in the DHT or can be selected as actor node (Profile Sampler or Target Finder) to recompose a secret. Note that DISPERS employs the basic SSSS and does not require more advanced (and much costlier) operations such as string-matching on secret-shares or order-preserving secret-sharing, e.g., as used in [27].

Anonymous communications can be obtained by using onion routing technique [58]. The sender selects all the routers and asymmetrically encrypts the message “in layers,” as an onion. Each router decrypts one layer and discovers dynamically the next router up to the destination.

A Merkle Hash Tree (MHT) [44] is a tree data structure for which leaf labels are hashes of data blocks $d_1, \dots , d_n$, and the remaining tree nodes are labeled with the hash of their children’s labels. The root of the tree is digitally signed allowing to check the integrity of any of the data blocks, computing the intermediary hashes, starting from the leaf, going up to the root and verifying that the computed root matches the signed one. MHTs are particularly useful to check the integrity of a given block $d_i$ without disclosing the others data blocks, but only the intermediate hashes in the MHT.

A verifiable random number generation protocol is a protocol which allows n nodes to produce a random value R, while guaranteeing that none of the n nodes can choose or influence the value of R. This is made possible if, at least, one of the n nodes is honest. A version of this protocol is described in details in our previous work [40] and is adapted from [8] which includes a formal proof. It roughly unfolds as following: (i) each node selects a random value $r_i$ and commits on it by sending $\mathtt {hash}(r_i)$ to a coordinator; (ii) the list of hash values, L, is disclosed by the coordinator to the n nodes; (iii) each node then checks that $\mathtt {hash}(r_i) \in L$ and, if so, sends $r_i$ and a signature of L back to the coordinator.

R is finally obtained by computing a XOR of the n individual random values. An attacker controlling $n - 1$ nodes cannot influence R since these nodes cannot change their $r_i$, committed with $\mathtt {hash}(r_i)$. Thus, the random value of a single honest node is enough to obtain a truly random final value.

Background on distributed hash tables

A Distributed Hash Table (DHT) in a P2P network [51] offers an optimized solution to the problem of locating the node storing a specific data item. The DHT offers a basic interface allowing nodes to store data, i.e., $\mathtt {store(key,value)}$, or to search for certain data, i.e., $\mathtt {lookup(key) \rightarrow value}$. DHT proposals share the concepts of keyspace or DHT virtual space (e.g., a 256 bits string obtained by hashing the key or the node ID with the SHA256 algorithm), space partitioning (mapping space partitions to nodes, using generally a distance function), and overlay network (routing tables and strategies allowing reaching a node, given its ID). For instance, the virtual space is represented as a multi-dimensional space in CAN [57], as a ring in Chord [66] or as a binary tree in Kademlia [42] and is uniformly divided among the nodes in the network. Thus, each node is responsible for the storage of all the $\mathtt {(key,~value)}$ pairs where the key falls in the subspace it manages. The $\mathtt {store}$ and $\mathtt {lookup}$ operations are fully distributed: DHTs do not require any central coordination. They are scalable, fault tolerant and provide a uniform distribution of the data.