You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
desired properties described previously, ProProx~\cite{ProProx}\footnote{Note
6
6
that~\cite{ProProx} uses the abbreviation PoPoK, we prefer \acs{PPK} for
7
7
shorter notation.}.
8
-
However, ProProx is not secure against a malicious verifier and does not provide \iac{PPK} protocol for quadratic residues (\ie protocols of the form \(\PPK[\alpha][a = \alpha^2]\)) while in our context, we need \iac{PPK} protocol for discrete logarithms (\ie\(\PPK[\alpha][a = g^\alpha]\)).
8
+
However, ProProx is not secure against a malicious verifier and does
9
+
not \sonja{I think ``not'' should be removed} provide \iac{PPK} protocol for quadratic residues (\ie protocols of the form \(\PPK[\alpha][a = \alpha^2]\)) while in our context, we need \iac{PPK} protocol for discrete logarithms (\ie\(\PPK[\alpha][a = g^\alpha]\)).
9
10
To realize this, we will now introduce such a protocol in order to enable us to have \ac{DB} anonymous credentials.
10
11
11
12
12
13
\emph{Reattempting a distance-bounding Schnorr protocol.}
13
14
In the original \ac{DB} paper by \citet{DistanceBounding}, one of the distance-bounding protocol is based on the Schnorr identification scheme~\cite{Schnorr}.
14
-
However, this \ac{DB} Schnorr protocol was shown to be prone to distance hijacking~\cite{DistanceHijacking}, in addition of also not being secure against terrorist fraud either.
15
-
We now propose another way to turn the Schnorr protocol into a public-key \iac{DB} protocol which is secure against \ac{DBMF}, \ac{DBDF}, \ac{DBDH}, \ac{DBTF} and an impersonating verifier.
15
+
However, this \ac{DB} Schnorr protocol was shown to be prone to distance hijacking~\cite{DistanceHijacking}, in addition to not being secure against terrorist fraud.
16
+
We now propose another way to turn the Schnorr protocol into a
17
+
public-key \iac{DB} protocol which is secure against \ac{DBMF},
18
+
\ac{DBDF}, \ac{DBDH}, \ac{DBTF} and an impersonating
19
+
verifier. \sonja{contrast with \ac{DBIF}}
16
20
17
21
We present the protocol in \cref{SchnorrFigure}.
18
-
The main difference with the original Schnorr protocol is that the prover commits to one random value but the verifier sends two challenges.
22
+
The main difference to the original Schnorr protocol is that the prover commits to one random value but the verifier sends two challenges.
19
23
The verifier presents to the prover which commitments and challenges to use during the \ac{DB} phase.
To achieve malicious-verifier zero-knowledge, choose \(k\) logarithmically with respect to the security parameter \(\lambda\) and repeat the protocol until the knowledge error is small enough.
97
101
This will actually also decrease the success probability of \iac{DBMF} adversary in the \ac{DB} step.
98
102
Indeed, the \ac{DBMF} adversary does not know which challenge the verifier will use, thus there is a \(1/2\) probability that the \ac{DBMF} adversary will guess it correctly.
99
-
The prover will only provide one of the responses: even if the adversary re-runs the protocol with the same challenges, the randomly chosen \(\rho_0, \rho_1\) will have changed --- which thus yields another \(R_b\)in the end of the protocol.
100
-
A sequential repetition of protocol will decrease this probability.
103
+
The prover will only provide one of the responses: even if the adversary re-runs the protocol with the same challenges, the randomly chosen \(\rho_0, \rho_1\) will have changed --- which thus yields another \(R_b\)at the end of the protocol.
104
+
A sequential repetition of the protocol will decrease this probability.
101
105
102
106
The \ac{DB} phase protects against distance fraud.
103
107
\Iac{DBDF} prover must wait for the challenge bit \(b_i\) before responding with \(r_i\).
The protocol is \ac{DBTF}-resistant, indeed if the malicious prover gives both responses to the adversary, the adversary can compute his secret key.
111
115
This follows from the fact that it is \iac{ZKPK}, which means there is an extractor that can leak the secret.
112
-
The protocol is also secure against distance hijacking due to the fact that it is the authenticated bitstring that is used during the \ac{DB} phase, not the challenge bitstring as in the protocol of Brands-Chaum.
116
+
The protocol is also secure against distance hijacking due to the fact
117
+
that it is the authenticated bitstring that is used during the \ac{DB}
118
+
phase, not the challenge bitstring as in the protocol of Brands-Chaum.
119
+
\sonja{this is analysis but not in the analysis section}
\Ac{DB} protocols precisely enable the verifier to estimate an upper bound on his distance to the prover by measuring the time-of-flight of short challenge-response messages (or rounds) exchanged during time-critical phases.
8
8
Time critical phases are complemented by slow phases during which the time is not taking into account.
9
9
At the end of a \Ac{DB} protocol, the verifier should be able to determine if the prover is legitimate AND in his vicinity.
10
-
In this sense, \Ac{DB} protocols combines at the same time the classical properties of authentication protocols with the possibility of verifying the physical proximity.
10
+
In this sense, \Ac{DB} protocols combine the classical properties of authentication protocols with the possibility of verifying the physical proximity.
11
11
12
12
The main attacks against \ac{DB} protocols can be summarized as follows:
\item\Acf{DBTF}: a legitimate but malicious prover helps an accomplice close to the verifier to authenticate.
17
17
%Seb: the two following properties should be defined more precisely
18
18
\item\Acf{DBDH}: similar to \ac{DBDF} but using the presence of an honest prover close to the verifier.
19
-
\item\Acf{DBIF}: the adversary plays against a simplified version of the protocol without any distance estimation.
19
+
\item\Acf{DBIF}: the adversary plays against a simplified version of the protocol without any distance estimation.\sonja{contrast with impersonating verifier}
20
20
\end{itemize}
21
21
There are two lines of attempts at formalizing the above properties: one by \citet{DB-BMV} and another by \citet{DB-DFKO}.
22
22
23
-
The majority of the existing \ac{DB} protocols are symmetric and thus requires an honest verifier.
23
+
The majority of the existing \ac{DB} protocols are symmetric and thus require an honest verifier.
24
24
Indeed, in this context it does not make sense to protect against the verifier as he can easily impersonate the prover as he has a knowledge of his secret key.
25
25
There has been less work done in the domain of asymmetric (or public-key) \ac{DB} protocols.
26
-
Unfortunately, our setting requires a public-key \ac{DB} protocol with a \emph{malicious verifier} who will potentially try to \emph{impersonate the prover}.
26
+
Our setting requires a public-key \ac{DB} protocol with a \emph{malicious verifier} who will potentially try to \emph{impersonate the prover}.
27
27
The verifier might also try to track the provers and map their identities to their actions, thus we also require privacy.
28
28
This leads to the requirement of a \ac{DB} \ac{ZKPK}, or simply \ac{PPK}, with resistance to all the frauds mentioned above as well as against a verifier who will attempt to impersonate the prover.
29
29
More specifically, we must combine such \iac{DB} with anonymous credentials (which we do in \cref{DB-anon-cred}).
Copy file name to clipboardExpand all lines: paper/LocationProofs.tex
+4-4
Original file line number
Diff line number
Diff line change
@@ -2,11 +2,11 @@ \subsection{Location proofs}
2
2
3
3
Some location-based services only grant access to resources to users located at a particular location, thus raising the issue of verifying the position claimed by a particular user.
4
4
In most of the existing schemes, the location of a user/device is determined by the device itself (\eg through GPS) and forwarded to the location-based service provider.
5
-
One of the main drawback of this approach is that a user can cheat by having his device transmitting a false location.
5
+
One of the main drawbacks of this approach is that a user can cheat by having her device transmit a false location.
6
6
Therefore, it is possible for a user to be inappropriately granted access to a particular resource while being thousands of kilometers away.
7
7
8
-
One possible way to counter this threat is by having the requesting device formally proven that it really is at the claimed location, which give rise to the concept of \emph{location proof}.
8
+
One possible way to counter this threat is by having the requesting device formally prove that it really is at the claimed location, which gives rise to the concept of \emph{location proof}.
9
9
In a nutshell, a location proof is a digital certificate attesting that someone was at a particular location at a specific moment in time.
10
-
A location proof system is a architecture by which users can obtain location proofs from neighboring witnesses (\eg trusted access points or other users) that can later be shown to verifiers who can check the validity of a particular proof \cite{luo2010veriplace, zhu2011applaus}.
10
+
A location proof system is an architecture by which users can obtain location proofs from neighboring witnesses (\eg trusted access points or other users) that can later be shown to verifiers who can check the validity of a particular proof \cite{luo2010veriplace, zhu2011applaus}.
11
11
Most of the existing approaches to location proofs require the prover and the witnesses to disclose their identities, thus raising many privacy issues such as the possibility of tracing the movements of users of the location proof architecture.
12
-
However, some location proofs systems, such as PROPS~\cite{PROPS}, exists that provides strong privacy guarantees along with the possibility of verifying the claim of the location. \PRIVOshare some similarities with PROPS, although their objective is quite different as it aims at verifying a global property of the population (\ie crowd estimation) in contrast to checking the location claim made by a user, which is an individual property.
12
+
However, some location proofs systems, such as PROPS~\cite{PROPS}, exist that provide strong privacy guarantees along with the possibility of verifying the claim of the location. \PRIVOshares some similarities with PROPS, although their objective is quite different as it aims at verifying a global property of the population (\ie crowd estimation) in contrast to checking the location claim made by a user, which is an individual property.
Second, since the phone has a unique identifier, participants might be uncomfortable to be registered in association with the event and might thus turn the device off, even though, at least with 5G, the IMSI number will not be transmitted anymore in plaintext. %need to cite?
66
66
Finally, there will be limited verifiability, as the data recorder must be trusted to record all data in relation to the protest.
67
67
68
-
An approach that relies on a trusted infrastructure was recently deployed by a collection of media outlets to count protesters passing the line defined by a trusted sensor on marches~\cite{LeMondeProtestingSolution}, is another recent development.
69
-
This solution does not offer strong verifiability guarantees and thus has complemented by micro-counts made by humans to estimate his margin of error.
68
+
An approach that relies on a trusted infrastructure was recently deployed by a collection of media outlets to count protesters passing the line defined by a trusted sensor on marches~\cite{LeMondeProtestingSolution}.
69
+
This solution does not offer strong verifiability guarantees and thus is complemented by micro-counts made by humans to estimate their margin of error.
70
70
71
-
In general for all of the above methods, the more a crowd spreads out, the more difficult it will be to determine its size.
72
-
In particular, one of the challenge is determining whether people near the event's perimeter are participants or simply bystanders~\cite{HowToEstimateCrowdSize}.
73
-
These methods also have difficulty to capture the actual attendance of an event (\ie, the cumulative participation, not just the count at a snapshot around the peak).
71
+
In general for all of the above methods, the more a crowd spreads out, the more difficult it is to determine its size.
72
+
In particular, one of the challenges is determining whether people near the event's perimeter are participants or simply bystanders~\cite{HowToEstimateCrowdSize}.
73
+
These methods also have difficulties capturing the actual attendance of an event (\ie, the cumulative participation, not just the count at a snapshot around the peak).
74
74
75
75
One of the most closely related work to our scheme is \citet{CrowdCount}, which is a web service that lets Alice create an event such that anyone can submit his location to register that he is in Alice's event.
76
76
This method has the benefit of counting everyone who has declared his presence, not just the count at the snapshot of the pictures.
77
-
However, there is no verification as the service must be trusted to behave honestly, but even then, nothing prevents Bob from submitting twice (violating eligibility, \cref{EligibilityVerif}).
77
+
However, there is no verification as the service must be trusted to behave honestly, but even then, nothing prevents Bob from submitting more than once (violating eligibility, \cref{EligibilityVerif}).
78
78
Another downside is that the service also requires an Internet connection during the event to register as a participant.
79
79
This makes it prone to some form of denial-of-service attack.
80
80
For instance, if Alice has organized a protest against Grace's regime, who shuts down the cellular network or Internet backbone as a means to censor the protest.
81
81
82
82
Another related approach based on devices is UrbanCount~\cite{UrbanCount}, which relies on epidemic spreading of crowd-size estimates by device-to-device communication to count crowds in dense urban environments with high node-mobility and churn.
83
-
However, there is no consideration of a potentially adversarial setting and thus no verification or checks on eligibility. DiVote~\cite{DiVote}, a prior work by the same authors for polling in dense areas, avoids double counting, but again only work with honest participants.
83
+
However, there is no consideration of a potentially adversarial setting and thus no verification or checks on eligibility. DiVote~\cite{DiVote}, a prior work by the same authors for polling in dense areas, avoids double counting, but again only works with honest participants.
Copy file name to clipboardExpand all lines: paper/SystemModel.tex
+12-5
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ \section{Defining and formalizing protest and crowd estimation}%
4
4
%\subsection{What is \protect\emph{a} protest?}%
5
5
%\label{WhatIsAProtest}
6
6
7
-
\emph{Defining the concept of protest.}
7
+
%\emph{Defining the concept of protest.}
8
8
To be able to estimate the participation count for a protest, we first need to define this concept and which quantity should be counted.
9
9
Let us start by considering some examples.
10
10
During the demonstrations against the South Korean president in Seoul in 2016
@@ -24,7 +24,14 @@ \section{Defining and formalizing protest and crowd estimation}%
24
24
varies over time.
25
25
26
26
For the rest of the paper, we will refer to the organizer as Alice.
27
-
Assume that the objective of Alice is to count everyone who participated at any time and in any of the locations~\cite{2016DemonstrationsInSeoul}\footnote{Remark that the objective does not necessarily align with the definition of the police whose interest could be to determine the maximum crowd at any point in time to deploy enough personnel for crowd-control.}.
27
+
Assume that the objective of Alice is to count everyone who
28
+
participated at any time and in any of the
29
+
locations~\cite{2016DemonstrationsInSeoul} \sonja{commented out for
30
+
repetition: %\footnote{Note that the objective does not necessarily
31
+
%align with the definition of the police whose interest
32
+
%could be to determine the maximum crowd at any point in
33
+
%time to deploy enough personnel for crowd-control.
34
+
}.
28
35
% cause identifier
29
36
Formally, we define a protest as an event that is uniquely identified by its cause \(\cid\), its time interval \(t\) and its location (area) \(l\).
30
37
More specifically, we will use the following definition.
@@ -48,7 +55,7 @@ \section{Defining and formalizing protest and crowd estimation}%
48
55
49
56
Our protocol relies on \emph{witnesses} to certify and associate the proof to the location by creating a \emph{proof share}.
50
57
A witness is only allowed to create one proof share per protester to avoid the risk of inflation.
51
-
Note that a participant to a protest can take the role of a protester but also act as witness for other protesters.
58
+
Note that a participant of a protest can take the role of a protester but also act as witness for other protesters.
52
59
%Seb: the sentence below is not very clear, it should be rephrased to make it clearer
53
60
The participation proof and its proof shares are stored in a set, as there should be only unique proof shares.
54
61
@@ -81,7 +88,7 @@ \section{Defining and formalizing protest and crowd estimation}%
of all proof shares with the same protester and protest identifiers, witnessing time interval \(t\) and location \(l\)is within those of the protest.
91
+
of all proof shares with the same protester and protest identifiers, witnessing time interval \(t\) and location \(l\) within those of the protest.
85
92
We denote by \(\prfs\) the set of all proofs.
86
93
\end{definition}
87
94
@@ -102,6 +109,6 @@ \section{Defining and formalizing protest and crowd estimation}%
102
109
The strength function \(\str\) can be used to regulate the trust in the participation count estimated.
103
110
One example would be for \(\str\) to return the number of unique witnesses and thus let \(\theta\) to be the threshold of the number of required witnesses.
104
111
%Seb: we should define clearly the different type of witnesses (for instance unique and trusted witnesses)
105
-
Another possibility would be to also have a particular type of witnesses, called trusted witnesses, participating to the protest.
112
+
Another possibility would be to also have a particular type of witness, called trusted witness, participating in the protest.
106
113
For instance, the role of the trusted witness could be taken by Jane, the independent journalist.
107
114
In this situation, the strength function could be defined with respect to the number of proof shares issued by trusted witnesses and set \(\theta = 1\) to require at least one proof share issued by a trusted witness.
0 commit comments