MP3: A More Efficient Private Presence Protocol

Abstract

This paper presents a novel private presence protocol, referred to as MP3, where the service provider does not have any knowledge of the social graph of its users. In prior work, a private presence protocol, referred to as DP5, was presented. However, the size of the presence database in this protocol grows rapidly as the number of users increases; this limits its scalability and increases its cost. In the proposed protocol, the size of the presence database is reduced significantly, enabling significantly cheaper registration and lookup compared to that of DP5. MP3 requires about two-thirds the bandwidth of DP5 for $N={200\,000}$ users and about one-half the bandwidth of DP5 for $N={1\,000\,000}$ users. Furthermore, these savings grow asymptotically with the number of users. Additionally, the client-facing latency in MP3 is an order of magnitude less than that of DP5. We provide an evaluation of the performance and scalability of both protocols.

Appendices

A Modifications to Dynamic Broadcast Encryption

Recall the operations of DBE from Sect. 3.3. Our modifications to DBE [7] only add the DBE.ShiftMK and DBE.ShiftDK operations. These operations are required for plausibly deniable revocations and suspensions. Recall that in a long-term database record for Alice in which Bob is actually revoked, Bob’s old decryption key ($\textit{dk}_{ab}$) is revoked and he is issued a new, but invalid, decryption key ($\textit{dk}_{ab}'$). Without DBE.ShiftMK and DBE.ShiftDK, Bob could use $\textit{dk}_{ab}'$ to invert the Update operation and detect whether he was revoked or not.

The inverse update function is:

• DBE.Update$^{-1}$($\textit{dk}'=(x', A', B', \kappa '), x_r, B_r$) - takes as input a decryption key and a revocation values and computes a new decryption key where that can decrypt ciphertexts created before the revocation.

Assuming DBE.ShiftMK and DBE.ShiftDK are not in place, a revoked user Bob can use DBE.Update$^{-1}$ to detect that he has been revoked by Alice. Given two long-term presence records of Alice, where the former has not revoked Bob and the latter has revoked Bob, Bob can apply the DBE.Update$^{-1}$ function to his new decryption key and compute a decryption key for the former presence record.

Let Bob’s decryption keys for the former presence record be $\textit{dk}_{ab}$ and let Bob’s decryption key for the latter presence record (after calling DBE.Update$^{-1}$) be $\textit{dk}_{ab}'$. Also let $C_1, C_2$ be the ciphertext components from the former presence record. To detect if he has been revoked, all he must do is check if $\textsc {DBE.Decrypt}(\textit{dk}_{ab}, C_1, C_2) \ne \textsc {DBE.Decrypt}(\textit{dk}_{ab}', C_1, C_2)$. If the statement is true, then Bob has been revoked by Alice.

By introducing DBE.ShiftMK and DBE.ShiftDK we create a one-way operation to the revocation process of MP3; thus Bob cannot invert the DBE.ShiftMK and DBE.ShiftDK functions without the knowledge of the plaintext of $(C_1, C_2)$ and therefore cannot detect whether or not he was revoked.

B Availability Against Malicious Parties

Some conventional approaches to ensure availability against malicious parties cannot be applied directly to privacy-preserving protocols, as they can leak information. This causes several challenges: keeping the databases small, ensuring the registration server stores all uploaded presence records, ensuring the lookup servers store all presence records and do not modify them.

A malicious client could upload many presence records during a given epoch, causing a denial of service (DoS) for all other clients. If a malicious client were using an anonymous channel, authentication would compromise the anonymity of that client, defeating the purpose of MP3. To eliminate this, k-times anonymous authentication schemes have been proposed [17, 18]. In these schemes, users are guaranteed anonymity up to k times; that is, if a user authenticates $k+1$ times, the identity of the user can be computed. Such private rate-limiting schemes can be used to limit the number of times a client registers during a given epoch without losing anonymity.

In the case that the registration server is dishonest and drops records, a user could “friend themself” to ensure that their presence records are being stored, by looking themself up during every epoch. Note that all presence records are indistinguishable, so the registration server can not target specific records for dropping.

Lastly, in the case that the lookup servers are dishonest and modify the database, Devet et al. propose a robust PIR scheme [19] that allows detection of malicious servers. This detection requires at least $t+2$ honest servers, where t is the number of servers needed to collude to be able to determine the data in a query. This robust PIR scheme is implemented in MP3.