Enabling Collaborative Privacy in User-Generated Emergency Reports

Abstract

Witnesses are of the utmost importance in emergency systems since they can trigger timely location-based status alerts. However, their collaboration with the authorities can get impaired for the fear of the people of being involved with someone, some place, or even with the same cause of the emergency. Anonymous reporting solutions can encourage the witnesses, but they also pose a threat of system collapse if the authority receives many fake reports. In this paper, we propose an emergency reporting system that ensures the anonymity of honest witnesses but is able to disclose the identity and punish the malicious ones. The system is designed over an online social network that facilitates the indistinguishability of the witness among a group of users. We use a game-theoretic approach based on the co-privacy (co-utility) principles to encourage the users of the network to participate in the protocol. We also use discernible ring signatures to provide the property of conditional anonymity. In addition, the system is designed to provide rewards to a witness and his/her group members in a privacy-preserving manner.

Appendices

A Basics of Game Theory

As detailed in [17], a game is a protocol between a set of N players, $\{P^1,\cdots ,P^N\}$ who must choose among a set $S_i$ of possible strategies. Let $s_i \in S_i$ be the strategy played by player $P^i$ and $S = \varPi _i S_i$ the set of all possible strategies for all players.

The vector of strategies $s \in S$ chosen by all players determines the outcome of the game for each player which can be thought of as a payoff or a cost. For all players, a preference ordering of these outcomes should be given in the form of a complete, transitive and reflexive relation on the set S. A simple and effective way of achieving this goal is by defining a scalar value for each outcome and each player. This value may represent a payoff (if positive) or a cost (if negative). A function that assigns a payoff to each outcome and each player is called a utility function: $u_i: S \longrightarrow \mathbb {R}$.

Given a strategy vector $s \in S$, $s_i$ denotes the strategy chosen by $P^i$, and let $s_{-i}$ denote the $(N-1)$-dimensional vector of the strategies chosen by all other players. With this notation, the utility $u_i(s)$ can also be expressed as $u_i(s_i,s_{-i})$. A strategy vector $s \in S$ is a dominant strategy solution if it yields the maximum utility for a player irrespective of the strategy played by all other players, i.e. for each alternate strategy vector $s'\in S$, maximum utility is $u_i(s_i,s'_{-i}) \ge u_i(s'_i,s'_{-i})$.

In addition, a strategy vector $s\in S$ is said to be a Nash equilibrium if it provides the largest utility for all players, larger than any other alternate strategy $s'_i \in S_i$ or $u_i(s_i,s_{-i}) \ge u_i(s'_i,s_{-i})$. This mean that, in a Nash equilibrium, no player will be able to change his/her strategy from $s_i$ and achieve a better payoff when all the other players have chosen their strategies in s. Note that Nash equilibria are self-enforcing if players behave rationally, since it is in all players’ best interest to stick to such a strategy. Obviously, if all players are in a dominant strategy solution at the same time, this is a Nash equilibrium. More game theory information can be found in [17].

B Threshold Discernible Ring Signatures

We base our system on threshold discernible ring signatures (TDS), which were introduced by Kumar et al. [14]. In a t-threshold discernible ring signature, a user in the system can generate a signature using his/her own private key and the public keys of the other n ring members (with $n > t$). A verifier is convinced that someone in the ring is responsible for the signature, but he/she cannot identify the real signer. The identity of the signer can only be revealed if a coalition of at least t members of the group cooperates to open the secret identity. In the following, three TDS operations that were used in the proposed protocol are outlined.

1.1 B.1 Signature

The signing algorithm $S_{TDS}(g,x_i,y_1,\cdots ,y_n,\alpha _1,\cdots ,\alpha _n,t,m)$ generates a ring signature of a message m and a set of verifiable encrypted shares of a secret that allows disclosing the identity of the original signer. The secret, which we call $f_0$, can only be revealed when a group of t ring members brings together some information. For signing a message m, the user first generates t random numbers $f_j \in Z_{q}^{*}$ and computes $F_j = g^{f_j}$ for each of them. The first random number $f_0$ is used as a trapdoor to hide the real signer of m, and hence, this $f_0$ is partitioned using the Shamir’s secret sharing scheme [20] and verifiably encrypted (VE) in n shares $V_{k}$, one for each user of the group, using the public parameters of all the group members $\{(y_{1}, \alpha _{1}), (y_{2}, \alpha _{2}), \cdots , (y_{n}, \alpha _{n})\}$.

$$\begin{aligned} s_{k} \leftarrow f_0 +&\sum _{j=1}^{t-1} f_{j}\alpha _{k}^{j}, k=1, \cdots , n, \\ V_{k} \leftarrow VE_{y_{k}}( s_{k} : g^{s_{k}} = \hat{g}&\prod _{j=1}^{t-1} F_{j}^{\alpha _{k}^{j}} ), k=1, \cdots , n, \text {where}, \hat{g} \leftarrow g^{l}. \end{aligned}$$

Then, the user generates another tuple of n random numbers $r_j \in Z_{q}^{*}$ and computes $w_j = g^{r_j}$ for each of them. He/She also calculates $\hat{y}_w \leftarrow \hat{g}^{x_i+r_i}$. Finally, he/she computes an equality signature [13] $(EC,ES) \leftarrow S_{SEQDL}(\hat{g}, g, x_i, r_i, \hat{y}_w, Y, W, m)$ and n knowledge signatures $\{(kc_k,ks_k) \leftarrow S_{SKDL}(g, w_k, m)$, $k=1, \cdots , n\}$ (with $Y \leftarrow y_1,\cdots ,y_n$,$W \leftarrow w_1,\cdots ,w_n$, $KC\leftarrow kc_1,\cdots ,kc_n$,$KS \leftarrow ks_1,\cdots ,ks_n$) that allow the signer to prove in zero-knowledge the integrity of the signed report and its group authenticity. The output of the signature algorithm is a threshold discernible ring signature $\sigma = (\sigma _1, \sigma _2)$ where, $\sigma _1 \leftarrow (\hat{g}, \hat{y_w}, Y, W, EC, ES, KC, KS)$ and $\sigma _2 \leftarrow (V, F)$ with $V \leftarrow V_1, \cdots , V_n$, and $F \leftarrow F_1, \cdots , F_t$.

1.2 B.2 Verification

The verification algorithm $V_{TDS}(m,\sigma )$ contains two actions: (1) checking the origin discernibility of the signature, i.e. the encrypted shares of the secret $f_0$ are verifiable and thus, a coalition of t users could reveal the identity of the signer,

$$\begin{aligned} \textstyle Verify (VE_{y_{k}}(s_{k}:g^{s_{k}}=\hat{g}\prod _{j=1}^{t-1} F_{j}^{\alpha _{k}^{j}} )=0, \text { for any } i=1,\cdots ,n). \end{aligned}$$

and (2) verifying the ring signature, i.e. checking that some member of the group with a valid private key has signed m and, thus, that m is authentic and integral. For this, a user first executes a proof of knowledge procedure [4] $V_{SKDL}(g,w_{k},m)$ for any $i=1,\cdots ,n$, to check that the signer knows the n random numbers $r_j \in Z_{q}^{*}$ used in the signature. Then, it executes the verification algorithm of the signature of knowledge of equality of discrete logarithms $V_{SEQDL}(\hat{g},g,\hat{y}_w,Y,W,EC,ES,m)$.

1.3 B.3 Threshold Distinguisher

The threshold distinguisher algorithm requires that at least t members of the ring decrypt their secret share $V_i$ with their private key $x_i$ to obtain $\rho _i$. Then, these users have to share their respective $\rho _i$’s to disclose the secret element of the signature $f_0$. This can be computed using Lagrange’s interpolation formula. After obtaining $f_0$, the users will be able to discover the signer of the message yielding the user $P^i$ that matches the following equation: $(y_iw_i)^f_{0} = \hat{y}_{w}$.

C The Reward Redemption Protocol

The EMS responds the witness, the hops and the reporter (immediately or after some days) with a reward for reporting a true emergency. The witness receives a reward encrypted with $k_m$, which is only known to the witness. The hops and the reporter receive the rewards encrypted with their corresponding public keys.

In order to redeem the rewards from the CC, the awardees proceed as follows. (1) Each awardee $A_i$ generates a pseudo-identity (PI) with the help of a CA. This PI is used by $A_i$ for redeeming a reward at the CC anonymously. (2) On receiving a request from $A_i$ for generation of PI, the CA selects a secret random number $b\in Z^*_{p}$, encrypts it with $A_i$’s public key and sends it to $A_i$. Thus, CA and all the awardees share a secret number b. $A_i$ deciphers b, selects a random number $a\in Z^*_{p}$ and uses his/her secret key to sign $\{ ID_{A_{i}}, \mathrm {Cert}_{CA}(A_i),b,a\}$. $A_i$ computes his/her PI by using a hash function: $PI_{{A_{i}}}= H(ID_{A_{i}},\mathrm {Cert}_{CA}(A_i),b,a, \mathrm {Sign}_{A_{i}}(\mathrm {Cert}_{CA}(A_i),b,a))$. (3) $A_i$ generates a key pair ($y^*_{A_{i}},x^*_{A_{i}}$), signs the public key with his/her private key, and sends $\mathrm {Sign}_{A_{i}}(y^*_{A_{i}},PI_{{A_{i}}})$ to CA. CA verifies the signature using the public key of $A_i$. If valid, CA generates an anonymous certificate $\mathrm {Cert}_{CA}(PI_{{A_{i}}},y^*_{A_{i}})$ and sends it to $A_i$. (4) $A_i$ sends a payoff redeem request, $payoff _{ Req } = \{ PI_{{A_{i}}},$ $\mathrm {Cert}_{CA}(PI_{{A_{i}}})\}$, to the CC. (5) CC verifies the received certificate from the CA of the system. If verified, CC generates a session key $k_{A_{i}}$, encrypts it with $A_i$’s public key and sends it to $A_{i}$. Otherwise, CC aborts the redemption process. (6) $A_{i}$ encrypts the received $payoff$ and the signed hash using $k_{A_{i}}$ and sends $payoff _{ Req } = \{C_{k_{A_{i}}}( payoff , {Sign_{KS_{EMS}}} (H_{EC})), \mathrm {Cert}_{CA}(PI_{{A_{i}}}),$ $PI_{{A_{i}}} \}$ to CC. (7) CC performs decryption with $k_{A_{i}}$ and obtains the clear text ${Sign_{KS_{EMS}}} (H_{EC})$ and $payoff$. CC first checks if $PI_{{A_{i}}}$ has already redeemed the $payoff$ by looking up $\{ {Sign_{KS_{EMS}}} (H_{EC})$, $payoff ,$ $PI_{{A_{i}}}\}$ in its database. If no such entry exists, CC sends ${Sign_{KS_{EMS}}} (H_{EC})$ to the EMS for validation. If the $payoff$ has already been redeemed by $PI_{{A_{i}}}$, CC aborts the redemption process. (8) If the received $H_{EC}$ is equal to the stored $H_{EC}$, the EMS sends $accept$ notification to the CC. On receiving $accept$, CC sends rewards to $A_i$. CC then sets a redemption flag to 1 and stores {$FL=1,\mathrm {Cert}_{CA}(A_i),PI_{{A_{i}}}, payoff ,$ ${Sign_{KS_{EMS}}} (H_{EC})\}$ in its database.