Efficient PublicKey Distance Bounding Protocol
 3 Citations
 1.6k Downloads
Abstract
Distance bounding protocols become more and more important because they are the most accurate solution to defeat relay attacks. They consist of two parties: a verifier and a prover. The prover shows that (s)he is close enough to the verifier. In some applications such as payment systems, using publickey distance bounding protocols is practical as no preshared secret is necessary between the payer and the payee. However, publickey cryptography requires much more computations than symmetric key cryptography. In this work, we focus on the efficiency problem in publickey distance bounding protocols and the formal security proofs of them. We construct two protocols (one without privacy, one with) which require fewer computations on the prover side compared to the existing protocols, while keeping the highest security level. Our construction is generic based on a key agreement model. It can be instantiated with only one resp. three elliptic curve computations for the prover side in the two protocols, respectively. We proved the security of our constructions formally and in detail.
Keywords
Distance bounding RFID NFC Relay attack Key agreement Mafia fraud Distance fraud Distance hijacking1 Introduction
Nowadays, various technologies, such as contactless payment (e.g. NFC), access control in a building, remote keyless system (e.g. car keys) are part of our lives since they provide us efficient usage of time and accessibility. However, these applications are exposed to simple but dangerous attacks such as relay attacks. A malicious person can abuse all these technologies by just relaying messages.
Distance bounding (DB) is a solution to detect the relay attacks. The detection of the attack is simpler, cheaper and more practical than preventing it because prevention could require a special hardware equipment [4]. The first DB protocol is introduced by Brands and Chaum [9]. Basically in DB, the verifying party measures the physical distance of the proving party by sending the challenges and receiving the responses (they are generally 1 or 2 bit(s)). In the end, if too many rounds have too long round trip times or too many incorrect responses, the verifier rejects the proving party since he may be exposed to a relay attack.
Threats for DB is not limited to only relay attacks. The other threats are the following:
Distance Fraud (DF): A malicious, faraway prover tries to prove that (s)he is close enough.
Mafia Fraud (MiM) [13]: A maninthemiddle (MiM) adversary between a verifier and a faraway honest prover tries to make the verifier accept.
Terrorist fraud (TF) [13]: A faraway malicious prover, with the help of the adversary, tries to make the verifier accept, but without giving any advantage to the adversary to later pass the protocol alone.
Distance Hijacking (DH) [12]: A faraway malicious prover takes advantage of some honest and active provers who are close to the verifier to make the verifier grant privileges to the faraway prover.
The review of the existing publickey DB protocols. \( \checkmark \) means that it is secure for corresponding threat model and \( \times \) means it is not. \( \checkmark ^* \) means that it is secure against the adversaries that cannot relay the messages close to the speed of light. EC is elliptic curve, ZK is zero knowledge, NIZK is noninteractive zero knowledge, AKA is authenticated key agreement. Public key (PK) computations are counted only on prover side. n is the number of rounds in the challenge phase and s is the security parameter.
Protocol  MiM  DF  DH  TF  Privacy  Strong privacy  PK computations for the prover 

BrandsChaum [9]  \( \checkmark \)  \( \checkmark \)  \( \times \)  \( \times \)  \( \times \)  \( \times \)  1 commitment, 1 signature 
HPO [20]  \( \checkmark \)  \( \checkmark \)  \( \times \)  \( \times \)  \( \checkmark \)  \( \times \)  4 EC multiplications 
GOR [17]  \( \checkmark \)  \( \checkmark \)  \( \times \)  \( \times \)  \( \times \)  \( \times \)  4 EC multiplications, 1 encryption, 1 NIZK proof 
PaySafe [11]  \( \checkmark ^* \)  \( \times \)  \( \times \)  \( \times \)  \( \times \)  \( \times \)  1 signature 
PrivDB [37]  \( \checkmark \)  \( \checkmark \)  \( \checkmark \)  \( \times \)  \( \checkmark \)  \( \checkmark \)  1 signature, 1 INDCCA encryption 
ProProx [38]  \( \checkmark \)  \( \checkmark \)  \( \checkmark \)  \( \checkmark \)  \( \times \)  \( \times \)  \( n + 1 \) commitments, n ZK proofs 
eProProx [35]  \( \checkmark \)  \( \checkmark \)  \( \checkmark \)  \( \checkmark \)  \( \checkmark \)  \( \checkmark \)  1 encryption, s hashing, \( n + 1 \) commitments, n ZK proofs 
SimppkDB  \( \checkmark \)  \( \checkmark \)  \( \times \)  \( \times \)  \( \times \)  \( \times \)  1 INDCCA decryption 
EffpkDB  \( \checkmark \)  \( \checkmark \)  \( \checkmark \)  \( \times \)  \( \times \)  \( \times \)  1 AKA protocol 
EffpkDB\(^p \)  \( \checkmark \)  \( \checkmark \)  \( \checkmark \)  \( \times \)  \( \checkmark \)  \( \checkmark \)  1 INDCCA Encryption, 1 AKA protocol 
DB protocols are categorized as symmetric DB protocols (the verifier and the prover share a secret) [5, 6, 7, 8, 16, 23, 24, 25, 34] and publickey DB protocols (the verifier and the prover only know the public key of each other) [9, 10, 17, 20, 35, 37, 38].
In some applications, we cannot assume that the prover and the verifier have established a secret. For example, in a payment system, it is not realistic to assume that the payment terminal and the customer share a secret. We can mention as an instance of a payment protocol the EMV standard [1] which now uses the publickey DB protocol PaySafe from [11]. However, this protocol sends nonces of several bits through the timecritical channel. Normally, a timecritical exchange should only take a few nanoseconds to reach a distance bound of meters with the speed of light, but sending a string of several bits typically takes microseconds. This is why usual DB protocols only exchange single bits through the timecritical phases. Actually, the protocol from [11] does not protect against adversaries running computations at the speed of light but only against adversaries using standard equipment which induce natural delays.
Although publickey distance bounding protocols are useful, it can cause considerable energy consumption on the prover side since publickey cryptography needs heavier computations than symmetrickey cryptography. Energy constraints on most of the powerless devices using RFID and NFC technologies cause very limited computation resources. One of the solutions could be to add more computational power to these devices but it increases their costs.
In this paper, we construct new protocols called EffpkDB, EffpkDB\( ^p \), and SimppkDB (EffpkDB\( ^p \) is the privacypreserving variant of EffpkDB).
Table 1 shows the security and the efficiency properties of previous protocols and our protocols. We can see that most of the previous publickey DB protocols [9, 10, 17, 35, 37, 38] do not concentrate on this efficiency problem, except HPO [20]. So far, HPO is the most efficient one among them since it requires only 4 elliptic curve (EC) multiplications on the prover side, but it is not strong private [36] and it is not secure against DH [22] and TF. In addition to this, its security is based on several adhoc assumptions [20] which are not so well studied: “OMDL”, “Conjecture 1”, “extended ODH” and “XL”.
GOR [17] was constructed to have strong privacy, but it has been shown in [36] that it is neither strong private nor private.
ProProx [38] satisfies all the security properties except privacy. Its version eProProx [35] is secure against all threat models and strong private. However, both ProProx and eProProx suffer from heavy cryptographic operations as zeroknowledge (ZK) proofs. These are the only TFsecure protocols, but we can see that their cost is unreasonable.
PrivDB [37] and our new protocol EffpkDB\(^p \) have the same security properties. However, PrivDB is a bit less efficient on the prover side than EffpkDB\(^p \) and it has no light privacyless variant, contrarily to EffpkDB\( ^p \).
Our lighter protocol EffpkDB and our first attempt SimppkDB in Appendix B are the most efficient publickey DB protocols as seen in Table 1. EffpkDB is secure against DF, MF, DH but it is not private. SimppkDB is secure only against DF, MiM and not private. It is more efficient than the BrandChaum protocol which has the same security level with SimppkDB. We focus on EffpkDB in the rest of the paper since it gives higher security level. EffpkDB’s variant EffpkDB\(^p \) uses one extra encryption and it is strong private. We propose an instance of these protocols based on the Gap DiffieHellman (GDH) problem [30] in EC with a random oracle. The detailed efficiency analysis is presented in Sect. 6.
PaySafe [11] is very efficient but we do not compare it with the other protocols and our protocols since it assumes weaker adversarial model. It is only secure against MiM. It is not secure against DF, DH and TF because the response of the prover in the time critical phase which is a nonce picked by the prover does not depend on any message of the verifier. It also does not protect the privacy of the prover.

We design two publickey DB protocols. The first protocol is secure against DF, MF and DH but it is not private. It uses only one public key related operation on the prover side. Basically, this protocol can be used in applications not requiring privacy in a very efficient way. Then, we modify this protocol by adding a publickey encryption to make it strong private. Both protocols are quite efficient compared with the previous protocols. Our constructions are generic based on a key agreement protocol, a weaklysecure symmetric DB protocols, and a cryptosystem. We formally prove the security following the model of BoureanuVaudenay [8] which was adapted to publickey DB in Vaudenay [37].

We define a new key agreement (KA) security game (DAKA). In literature, the extended CanettiKrawczyk (eCK) security model [27] is widely accepted for KA. However, a weaker security model (DAKA) is sufficient for the security of our new publickey DB protocols since we care both the efficiency and the security. Finally, we design a DAKA secure key agreement protocol (NonceDH) based on the hardness of the GDH problem and a random oracle. The NonceDH key agreement protocol can be used in our DB constructions.
We show in Appendix B another reasonable protocol SimppkDB which was our first attempt to construct an efficient and a secure protocol. Although this protocol is quite efficient and does not require any publickey of a verifier, it fails in DHsecurity. This shows that it is hard to make a protocol which is secure for MiM, DF, and DH at the same time. Adding privacy in protocols is yet another challenge. Strong privacy cannot be achieved so easily as shown in Sect. 5.2. HPO and GOR failed to on this.
Organization of the paper: In Sect. 2, we give the formal definitions for the notion of DB and all necessary security definitions we are considering in our new protocols. In Sect. 3, we describe one time DB protocol OTDB [37] and give new security results on this protocol. OTDB and all the results about OTDB can be employed by EffpkDB or EffpkDB\(^p \) in a very efficient way. In Sect. 4, we introduce our new and weaker KA security model (DAKA). Then, we construct a new KA protocol NonceDH which is DAKA secure. We have NonceDH to show that both EffpkDB and EffpkDB\(^p \) can employ it and to make more precise efficiency analysis on these protocols. In Sect. 5, we introduce EffpkDB and EffpkDB\(^p \) with all security and privacy proofs. Finally, in Sect. 6, we do the efficiency and security analyses of all previous publickey DB protocols in detail.
2 Definitions
The formalism in DB started by Avoine et al. [2]. Then, the first complete model was introduced by Dürholz et al. [15] where the threat models are defined according to the number of tainted time critical phase. The SKI model by Boureanu et al. [5, 6, 7] is another formal model which includes a clear communication model between parties in DB. The last model BV model [8] by Boureanu and Vaudenay is a more natural multiparty security model.
In this section, we give the definitions from the literature that we use in our security proofs.
2.1 Public Key Distance Bounding
Definition 1
(Public key DB Protocol [37]). A public key distance bounding protocol is a twoparty probabilistic polynomialtime (PPT) protocol and it consists of a tuple \( (\mathcal {K}_P,\mathcal {K}_V,V,P,B) \). Here, \( (\mathcal {K}_P,\mathcal {K}_V) \) are the key generation algorithms of P and V, respectively. The output of \( \mathcal {K}_P \) is a secret/public key pair \( (\mathsf {sk}_P,\mathsf {pk}_P) \) and similarly the output of \( \mathcal {K}_V\) is a secret/public key pair \( (\mathsf {sk}_V,\mathsf {pk}_V )\). P is the proving algorithm, V is the verifying algorithm where the inputs of P and V are from \( \mathcal {K}_P \) and \( \mathcal {K}_V \). B is the distance bound. \( P(\mathsf {sk}_P,\mathsf {pk}_P, \mathsf {pk}_V) \) and \( V(\mathsf {sk}_V, \mathsf {pk}_V) \) interact with each other. At the end of the protocol, \( V(\mathsf {sk}_V, \mathsf {pk}_V) \) outputs a final message \( \mathsf {Out}_V \) and have \( \mathsf {pk}_P \) as a private output. If \( \mathsf {Out}_V = 1 \), then V accepts. If \( \mathsf {Out}_V = 0 \), then V rejects.
A publickey DB protocol is correct if and only if under honest execution, whenever a verifier \( \mathcal {V}\) and a close (to \( \mathcal {V}\)) prover \( \mathsf {P}\) run the protocol, then \( \mathcal {V}\) always outputs \( \mathsf {Out}_V = 1 \) and \( \mathsf {pk}_P \).
Remark that this definition combines identification with DB: \( \mathsf {pk}_P \) is not an input of the algorithm V, but it is an output. So, V learns the identity of P during the protocol.
We formalize the security notions of DB protocols. In the setting below, we have parties called provers, verifiers and other actors. Each party has instances and each instance I has its own location. It is called close to the instance J, if \( d(I,J) \le B\) and far from J, if \( d(I,J) > B \) where d is a distance function.
An instance of an honest prover runs the algorithm denoted by \( P(\mathsf {sk}_P,\mathsf {pk}_P, \mathsf {pk}_V) \). An instance of a malicious prover runs an arbitrary algorithm denoted by \( P^*\). The verifier is always honest and its instances run \( V(\mathsf {sk}_V,\mathsf {pk}_V) \). Without loss of generality, we say that the other actors are malicious. They may run any algorithm.
The locations of the participants are elements of a metric space. We summarize the communication and adversarial model (See [5] for the details):
DB protocols run in natural communication settings. There is a notion of time, e.g. timeunit, a notion of measurable distance and a location. Besides, timed communication follows the laws of physics, e.g., communication cannot be faster than the speed of light. An adversary can see all messages (whenever they reach him). He can change the destination of a message subject to constraints.
This communication and adversarial model will only play a role in the DF and MiM security (defined below) but we will not have to deal with it. Indeed, we will start from an existing weakly secure symmetric DB protocol (such as OTDB [37]) and reduce the DF and MiM security of our protocol to the security of that protocol. So, we do not need to formalize more this model.
Now, we explain the security games for the distance fraud, mafia fraud and distance hijacking from [37].
Definition 2
(Distance fraud [37]). The game begins by running the key setup algorithm \( \mathcal {K}_V \) which outputs \( (\mathsf {sk}_V, \mathsf {pk}_V) \). The game includes a verifier instance \( \mathcal {V}\) and instances of an adversary. Given \( \mathsf {pk}_V \), the adversary generates \( (\mathsf {sk}_P, \mathsf {pk}_P) \) with an arbitrary key setup algorithm \( \mathcal {K}^*(\mathsf {pk}_V) \) (instead of \( \mathcal {K}_P \)). There is no participant close to \( \mathcal {V}\). The adversary wins if \( \mathcal {V}\) outputs \( \mathsf {Out}_V = 1\) and \(\mathsf {pk}_P \). A DB protocol is DFsecure, if for any such game, the adversary wins with negligible probability.
Definition 3
(Mafia fraud (MiM security) [37]). The game begins by running the key setup algorithms \( \mathcal {K}_V \) and \( \mathcal {K}_P \) which output \( (\mathsf {sk}_V, \mathsf {pk}_V) \) and \( (\mathsf {sk}_P, \mathsf {pk}_P) \), respectively. The adversary receives \( \mathsf {pk}_V \) and \( \mathsf {pk}_P \). The game consists of several verifier instances including a distinguished one \( \mathcal {V} \), an honest prover \( \mathsf {P}\) with its instances which are far away from \( \mathcal {V}\) and an adversary with its instances at any location. The adversary wins if \( \mathcal {V}\) outputs \( \mathsf {Out}_V = 1\) and \(\mathsf {pk}_P \). A DB protocol is MiMsecure if for any such game, the probability of an adversary to win is negligible.
Definition 4
(Distance hijacking [37]). The game consists of several verifier instances \( \mathcal {V}, V_1,V_2,... \), a far away adversary \( \mathsf {P}\), and also honest prover instances \( \mathsf {P}', \mathsf {P}_1',\mathsf {P}_2'... \). A DB protocol \( (\mathcal {K}_P,\mathcal {K}_V,V,P,B) \) having an initialization, a challenge and a verification phases is DHsecure if for all PPT algorithms \( \mathcal {K}^*_P \) and \( \mathcal {A} \), the probability of \( \mathsf {P}\) to win the following game is negligible.

\( \mathcal {K}_V \rightarrow (\mathsf {sk}_V, \mathsf {pk}_V) \), \( \mathcal {K}_{P'}\rightarrow (\mathsf {sk}_{P'}, \mathsf {pk}_{P'}) \).

\( \mathcal {K}_P^*(\mathsf {pk}_{P'},\mathsf {pk}_V) \rightarrow (\mathsf {sk}_P,\mathsf {pk}_P)\) and if \( \mathsf {pk}_P = \mathsf {pk}_{P'} \), the game aborts. Then, instances of \( \mathsf {P}\) run \( \mathcal {A}(\mathsf {sk}_P,\mathsf {pk}_P,\mathsf {pk}_V,\mathsf {pk}_{P'}) \), \( \mathsf {P}' ,\mathsf {P}'_1, \mathsf {P}'_2,... \) run \( P(\mathsf {sk}_{p'},\mathsf {pk}_V) \), \( \mathcal {V},V_1, V_2,... \) run \( V(\mathsf {sk}_V,\mathsf {pk}_V) \).

\( \mathsf {P}\) interacts with \( \mathsf {P}' , \mathsf {P}'_1, \mathsf {P}'_2,... \) and \( \mathcal {V},V_1, V_2,... \) during the initialization phase of \( \mathcal {V}\) and \( \mathsf {P}' \) concurrently.

\( \mathsf {P}' \) and \( \mathcal {V}\) continue interacting with each other in their challenge phase and \( \mathsf {P}\) remains passive even though he sees the exchanged messages.

\( \mathsf {P}\) interacts with \( \mathsf {P}' , \mathsf {P}'_1, \mathsf {P}'_2,... \) and \( \mathcal {V}, V_1, V_2,... \) in the verification phase concurrently.
The adversary wins if \( \mathcal {V}\) outputs \( \mathsf {Out}_V = 1\) and \(\mathsf {pk}_P \).
The notion of initialization/challenge/verification phase is arbitrary but the notion of DHsecurity depends on this. To make it correspond to the notion in [12], the challenge phase must correspond to the time critical part where the verifier and the prover exchange challenge/response so fast that responses from far away would be rejected.
Definition 5

\( \mathtt {CreateP}(ID)\rightarrow P_i :\) It creates a new prover identity of ID and returns its identifier \( P_i \).

\( \mathtt {Launch()}\rightarrow \pi : \) It launches a new protocol with the verifier \( V_j \) and returns the session identifier \( \pi \).

\( \mathtt {Corrupt}(P_i): \) It returns the current state of \( P_i \). Current state means the all the values in \( P_i \)’s current memory. It does not include volatile memory.

\( \mathtt {DrawP}(P_i,P_j) \rightarrow vtag:\) It draws either \( P_i \) (if \( b = 0\)) or draws \( P_j \) (if \( b = 1 \)) and returns the virtual tag reference vtag. If one of the provers was already an input of \( \mathtt {DrawP} \rightarrow vtag'\) query and \( vtag' \) has not been released, then it outputs \( \emptyset \).

\( \mathtt {Free}(vtag): \) It releases vtag which means vtag can no longer be accessed.

\( \mathtt {SendP}(vtag,m)\rightarrow m': \) It sends the message m to the drawn prover and returns the response \( m' \) of the prover. If vtag was not drawn or was released, nothing happens.

\( \mathtt {SendV}(\pi ,m)\rightarrow m': \) It sends the message m to the verifier in the session \( \pi \) and returns the response \( m' \) of the verifier. If \( \pi \) was not launched, nothing happens.

\( \mathtt {Result}(\pi )\rightarrow b': \) It returns a bit that shows if the session \( \pi \) is accepted by the verifier (i.e. the message \( \mathsf {Out}_V \)).
In the end of the game, the adversary outputs a bit g. If \( g = b \), then \( \mathcal {A} \) wins. Otherwise, it loses.
A DB protocol is strong private if for all PPT adversaries, the advantage of winning the privacy game is negligible.
We distinguish strong and weak privacy [33]. The weak privacy game does not include any ‘Corrupt’ oracle. The other kind of classification is wide and narrow private. Wide privacy game is allowing to use the ‘Result’ oracle while the narrow privacy game does not. In this paper, we implicitly consider wide privacy by making \( \mathsf {Out}_V \) a protocol message, which means we always obtain this bit without using ‘Result’ oracle.
2.2 Symmetric Distance Bounding
In this section, we give the useful definitions about the symmetric distance bounding that we need to use for our public key distance bounding protocols. Therefore, we do not explain all security notions for symmetric DB protocols.
Definition 6
(Symmetric DB Protocol [37]). A symmetric distance bounding protocol is a twoparty PPT protocol and it consists of a tuple \( (\mathcal {K},V,P,B) \). Here, \( \mathcal {K}\) is the key generation algorithm, P is the proving algorithm and V is the verifying algorithm. The inputs of P and V is the output s of \( \mathcal {K} \). B is the distance bound. P(s) and V(s) interact with each other. At the end of the protocol, V(s) outputs a final message \( \mathsf {Out}_V \). If \( \mathsf {Out}_V = 1 \), then V accepts. If \( \mathsf {Out}_V = 0 \), then V rejects.
A symmetric DB protocol is correct if and only if under honest execution, whenever a verifier \( \mathcal {V}\) and a close (to \( \mathcal {V}\)) prover \( \mathsf {P}\) run the protocol, then \( \mathcal {V}\) always outputs \( \mathsf {Out}_V = 1 \).
Definition 7
(One Time DF (OTDF) [37]). The game begins by running a malicious key setup algorithm \( K^* \) which outputs s. It consists of a single verifier instance \( \mathcal {V}\) running V(s) and instances of an adversary \( P^* \). \( P^* \) receives s. There is no participant close to \( \mathcal {V}\). The adversary wins if \( \mathcal {V}\) outputs \( \mathsf {Out}_V = 1 \). A symmetric DB protocol is OTDFsecure, if for any such game, the adversary wins with negligible probability.
Definition 8
(One Time MiM (OTMiM) [37]). The game begins by running the key setup algorithm \( \mathcal {K} \) which outputs s. It consists of a single verifier instance \( \mathcal {V}\) running V(s) , a single far away prover instance \( \mathsf {P}\) running P(s) and instances of an adversary. The adversary wins if \( \mathcal {V}\) outputs \( \mathsf {Out}_V = 1 \). A symmetric DB protocol is OTMiMsecure, if for any such game, the probability that the adversary wins is negligible.
Multiverifier OTMiM: The OTMiM game with more than one verifier instance is called as multiverifier OTMiMsecurity. We defined this new notion to be able to have the result in Theorem 1 which helps us to prove the security of our constructions.
Definition 9
(One Time DH (OTDH) [37]). The game consists of a verifier instance \( \mathcal {V}\), a far away adversary \( \mathsf {P}\), and also honest (and close) prover instance \( \mathsf {P}' \). A symmetric DB protocol \( (\mathcal {K},V,P,B) \) having an initialization, a challenge and a verification phases is OTDHsecure if for all PPT algorithms \( \mathcal {A}, \mathcal {K}^* \), the probability of \( \mathsf {P}\) to win the following game is negligible.

\( \mathcal {K}^* \rightarrow s\), \( \mathcal {K} \rightarrow s' \) . Then, \( \mathsf {P}' \) runs \( P(s') \), \( \mathcal {V}\) runs V(s) and \( \mathsf {P}\) runs \( \mathcal {A} (s)\).

\( \mathsf {P}\) interacts with \( \mathsf {P}' \) and \( \mathcal {V}\) in their initialization phase concurrently.

\( \mathsf {P}' \) and \( \mathcal {V}\) continue interacting with each other in their challenge phase and \( \mathsf {P}\) remains passive even though he sees the exchanged messages.

\( \mathsf {P}\) interacts with \( \mathsf {P}' \) and \( \mathcal {V}\) in their verification phase concurrently.
The adversary wins if \( \mathcal {V}\) outputs \( \mathsf {Out}_V = 1 \).
Definition 10
(Multiverifier Impersonation Fraud (IF) [3]). The game begins by running the key setup algorithm \( \mathcal {K}\) which outputs s. It consists of verifier instances running V(s) and an adversary with no inputs. The adversary wins if any verifier instance outputs \( \mathsf {Out}_V = 1 \). A distance bounding protocol is multiverifier IFsecure, if for any such game, the probability of an adversary to win is negligible.
The above definition is with several verifiers, contrarily to others, because we will only use multiverifier IF security.
MiMsecurity covers multiverifier IFsecurity. So, if a DB protocol is MiMsecure, then it is multiverifier IFsecure.
We will see in Theorem 2 that OTMiMsecurity also implies multiverifier IFsecurity for a DB following the canonical structure.
Definition 11
(Canonical Structure [37]). A symmetric DB protocol \( (\mathcal {K},V,P,B) \) follows the canonical structure, if there exist an initialization/challenge/verification phases, \( \mathsf {P}\) does not use s during the initialization phase, \( \mathcal {V}\) does not use s at all except for computing the final \( \mathsf {Out}_V \), and the verification phase is not interactive.
Remark that the notion of phase is used in DH and OTDH security.
3 OTDB
As an example of onetime secure protocol, we can give the protocol OTDB by Vaudenay [37] which is a symmetric DB adapted from HanckeKuhn protocol [18]. The OTDB protocol follows the canonical structure (See Definition 11), only requires one xor operation before the challenge phase on the prover side and it is OTDF, OTMiM, multiverifier OTMiM and OTDH secure [37]. (See Fig. 1.) We complement these known results by showing multiverifier OTMiM security and multiverifier IFsecurity.
Theorem 1
OTDB is multiverifier OTMiM secure.
Proof
\( \varGamma _0 \): In this game, an adversary \( \mathcal {A} \) plays multiverifier OTMiM game. Here, we have a distinguished verifier instance \( \mathcal {V}\) with other instances \( \{V_1,...,V_k\} \) and one prover instance \( \mathsf {P}\). The success probability of \( \varGamma _0 \) is \( p_0 \).
\( \varGamma _1: \) We reduce \( \varGamma _0 \) to \( \varGamma _1 \) where at most one verifier instance outputs 1. Let’s say E is an event in \( \varGamma _0 \) where at least two verifier instances output 1 (\( \mathsf {Out}_V = 1 \)). To reduce \( \varGamma _0 \) to \( \varGamma _1 \), we show that \( \Pr [E] \) is negligible.
First, we define hybrid games \( \varGamma _{i,j} \)’s to analyze \( \Pr [E] \). \( \varGamma _{i,j} \) is similar to \( \varGamma _0 \) except the game stops right after \( V_i \) and \( V_j \) have sent their final outputs and all \( \mathsf {Out}_V \) is replaced by 0 except \( V_i \) and \( V_j \). The adversary wins the game if \( \mathsf {Out}_{V_i} = \mathsf {Out}_{V_j} = 1 \).
\( \varGamma _2: \) We reduce \( \varGamma _1 \) to \( \varGamma _2 \) where we simulate all verifier instances except \( \mathcal {V}\). We can do this simulation because the messages but \( \mathsf {Out}_V \) sent by a verifier does not depend on the secret. Since \( \mathsf {Out_V} = 0 \) for all verifier instance except \( \mathcal {V}\) in the winning case (only \( \mathcal {V}\) can output 1), \( p_1 \le p_2 \).
Now in \( \varGamma _2 \), we are in OTMiM game where there is only one verifier instance \( \mathcal {V}\) and one prover instance \( \mathsf {P}\). By using the OTMiMsecurity result of OTDB [37], we deduce \( p_2 \) is negligible so \( p_0 \) is negligible. \(\square \)
We prove the following result which will be used in Theorem 6.
Theorem 2
If a (symmetric) DB protocol following the canonical structure is OTMiM secure, then it is multiverifier IFsecure.
Proof
We take an adversary \( \mathcal {M} \) playing the multiverifier IF game. \( \mathcal {M} \) interacts with polynomially many verifier instances \( V_j \)’s. We define adversaries \( \mathcal {A}_i \)’s playing the OTMiM game. \( \mathcal {A}_i \) simulates \( \mathcal {M} \) and takes the verifier instance \( V_i \) as \( \mathcal {V}\) in the OTMiM game. Concretely, we number the \( V_j \)’s by their order of appearance during the simulation of \( \mathcal {M} \). When \( \mathcal {M} \) queries \( V_1,...,V_{i1}, V_{i+1},..., V_k \) (where k is the total number of verifier instances), \( \mathcal {A}_i \) just simulates them (this is possible since the protocol follows the canonical structure. So, no message from the verifier except \( \mathsf {Out}_V \) depends on s). If \( \mathsf {Out}_V \) needs to be returned to \( \mathcal {M} \), \( \mathcal {A}_i \) returns 0. When \( \mathcal {M} \) queries \( V_i \), \( \mathcal {A}_i \) relays it to \( \mathcal {V}\) and sends the response of \( \mathcal {V} \) to \( \mathcal {M} \).
Let \( E_i \) be the event in the multiverifier IF game which is \( \mathsf {Out}_{V_i} = 1\) and all previously released \( \mathsf {Out}_V \) are equal to 0. Clearly, we have \( \Pr [\mathcal {M} \, \mathsf {wins}] = \sum _{i \ge 1}\Pr [\mathcal {M} \, \mathsf {wins}\wedge E_i]\). On the other hand, \( \Pr [\mathcal {M} \, \mathsf {wins} \wedge E_i] \le \Pr [\mathcal {A}_i \, \mathsf {wins}]\) because for all coins making \( \mathcal {M} \) win the multiverifier IFgame and \( E_i \) occur at the same time, we have \( \mathsf {Out}_{V_j} = 0 \) for all \( j < i \) and \( \mathsf {Out}_{V_i} = 1 \) so the same coins make \( \mathcal {A}_i \) win the OTMiM game. So, \( \Pr [\mathcal {M} \, \mathsf {wins}] \le \sum _{i \ge 1} \Pr [\mathcal {A}_i \, \mathsf {wins}]\). Due to OTMiM security, \( \Pr [\mathcal {A}_i \, \mathsf {wins}] \) is negligible for every i. So, \( \Pr [\mathcal {M} \, \mathsf {wins}] \) is negligible. So, we have multiverifier IFsecurity. \(\square \)
Thanks to Theorem 2, OTDB is multiverifier IFsecure.
4 Authenticated Key Agreement (AKA) Protocols
In this section, we show our new KA security model and some preliminaries about the AKA protocols. The security models in this section are used to construct secure and private publickey DB protocols in Sect. 5.
We note that the DB protocols we constructed in Sect. 5 can employ any eCKsecure [27] key agreement protocol to have the same security properties. However, eCKsecurity is stronger than we need in our protocols. Therefore, we define a weaker notion to have simpler, more efficient and secure publickey DB. Table 3 in Appendix A shows that NonceDH which is secure in our weaker model is more efficient than the previous KA protocols.
Definition 12
(AKA in onepass). A onepass AKA protocol is a tuple \( (\mathsf {Gen}_A,\) \( \mathsf {Gen}_B, D, A, B) \) of PPT algorithms. Let A and B be the two parties. A and B generate secret/public key pairs \( (\mathsf {sk}_A, \mathsf {pk}_A) \) and \( (\mathsf {sk}_B, \mathsf {pk}_B) \) with the algorithms \( \mathsf {Gen}_A(1^n) \) and \( \mathsf {Gen}_B(1^n) \), respectively where n is the security parameter. B picks N from the sampling algorithm D and runs \( B(\mathsf {sk}_B, \mathsf {pk}_B, \mathsf {pk}_A,N) \) which outputs the session key s. Then, (s)he sends N and finally, A gets the session key s by running \( A(\mathsf {sk}_A, \mathsf {pk}_A,\mathsf {pk}_B,N) \) (See Fig. 2). We say that AKA is correct, if A and B obtain the same s at the end of the protocol.
Definition 13
 1.
Challenger executes \( \mathsf {Gen}_A(1^n)\rightarrow (\mathsf {sk}_A, \mathsf {pk}_A), \mathsf {Gen}_B(1^n) \rightarrow (\mathsf {sk}_B, \mathsf {pk}_B) \), sets up the oracles, calls \( \mathcal {O}_B(\mathsf {pk}_A) \rightarrow (s_0,N) \) and picks \( s_1 \in \{0,1\}^n \). Then, he sends \( s_b, N, \mathsf {pk}_B, \mathsf {pk}_A \) to the adversary \( \mathcal {A} \).
 2.
\( \mathcal {A} \) has access to the oracle \( \mathcal {O}_B(.) \) and \( \mathcal {O}_A(.,.) \) under the condition of not querying the oracle \( \mathcal {O}_A \) with the input \( (\mathsf {pk}_B,N) \). Eventually, \( \mathcal {A} \) outputs \( b' \).
 3.The advantage of the game is$$\begin{aligned} \mathsf {Adv}(\mathsf {KA}^{daka}_{\mathcal {A}(n)}) = \mathsf {Pr}[\mathsf {KA}^{daka}_{0,\mathcal {A}(n)} = 1]  \mathsf {Pr}[\mathsf {KA}^{daka}_{1,\mathcal {A}(n)} = 1]. \end{aligned}$$
A KA protocol (\( \mathsf {Gen}_A(1^n),\mathsf {Gen}_B(1^n),D,A,B\)) is DAKA secure if for all PPT algorithms \( \mathcal {A} \), \( \mathsf {Adv}(\mathsf {KA}^{daka}_{\mathcal {A}(n)}) \) is negligible.
We show that eCKsecurity implies DAKA security in Theorem 8 in Appendix A. It means that our new publickey DB protocols can employ eCKsecure key agreement protocols as well.
Note that as a result of Lemma 1 in Appendix A, the probability that the same nonce is picked by the oracle B is negligible when we have DAKA security.
Definition 14
 1.
Challenger runs \( \mathsf {Gen}_A(1^n) \rightarrow (\mathsf {sk}_A,\mathsf {pk}_A) \) and \(\mathsf {Gen}_B(1^n)\rightarrow (\mathsf {sk}_{B_1},\mathsf {pk}_{B_1})\) , sets up the oracle and gives \( \mathsf {pk}_A ,\mathsf {pk}_{B_1}\) and \( \mathsf {sk}_{B_1} \) to \( \mathcal {A} \).
 2.
\( \mathcal {A} \) selects \( \mathsf {sk}_{B_0} \) and \( \mathsf {pk}_{B_0} \) and sends them to the challenger.
 3.
Challenger executes \( D(1^n) \rightarrow N \), \( B(\mathsf {sk}_{B_b}, \mathsf {pk}_{B_b}, \mathsf {pk}_A^{\mathsf {sk}_{B_b}},N) \rightarrow s\). Then, he sends s to the adversary \( \mathcal {A} \).
 4.
\( \mathcal {A} \) has access to the oracle \( \mathcal {O}_A \). Eventually, \( \mathcal {A} \) outputs \( b' \). (Remark that \( \mathcal {A} \) does not know N.)
 5.The advantage of the game is$$\begin{aligned} \mathsf {Adv}(\mathsf {KA}^{daka^p}_{\mathcal {A}(n)}) = \mathsf {Pr}[\mathsf {KA}^{daka^p}_{0,\mathcal {A}(n)} = 1]  \mathsf {Pr}[\mathsf {KA}^{daka^p}_{1,\mathcal {A}(n)} = 1]. \end{aligned}$$
A KA protocol (\( \mathsf {Gen}_A(1^n),\mathsf {Gen}_B(1^n),D,A,B\)) is DAKA\(^p \) private if for all PPT algorithms \( \mathcal {A} \), \( \mathsf {Adv}(\mathsf {KA}^{daka^p}_{\mathcal {A}(n)}) \) is negligible.
A OnePass AKA Protocol (NonceDH): We construct a DAKA secure protocol (NonceDH) based on the DiffieHellman (DH) [14] as in Fig. 3. Here g is a generator of a group of prime order q. g and q depend on a security parameter. The parties know each others’ public keys beforehand where \( \mathsf {pk}_A = g^{\mathsf {sk}_A} \) and \( \mathsf {pk}_B = g^{\mathsf {sk}_B} \) and \( \mathsf {sk}_A \) and \( \mathsf {sk}_B \) are the corresponding secret keys which are uniformly picked in \( \mathbb {Z}_q \).
The party B has input \( (\mathsf {sk}_B,\mathsf {pk}_B,\mathsf {pk}_A) \). He randomly picks N from \( \{0,1\}^\ell \) and computes \( {B}( \mathsf {sk}_B, \mathsf {pk}_B,\mathsf {pk}_A, N ) = H(g,\mathsf {pk}_B, \mathsf {pk}_A, \mathsf {pk}_A^{ \mathsf {sk}_B},N) \) to get s. The party A computes \( A(\mathsf {sk}_A,\mathsf {pk}_A,\mathsf {pk}_B,N) = H(g,\mathsf {pk}_B, \mathsf {pk}_A,\mathsf {pk}_B^{ \mathsf {sk}_A},N) \) and gets s. Here, H is a deterministic function.
Theorem 3
Assuming that the Gap DiffieHellman problem [30] is hard and \( \ell = \varOmega (n) \), NonceDH is DAKA secure and DAKA\(^p \) private in the random oracle model.
The proof is in Appendix C.
5 Efficient Public Key Distance Bounding Protocol
In this section, we first introduce EffpkDB which is secure against DF, MF and DH and then EffpkDB\(^p \) a variant of it preserving the strong privacy as well.
5.1 EffPkDB
Theorem 4
If symDB is OTDFsecure, then EffpkDB is DFsecure.
Proof sketch: The malicious and far away prover with its instances play the DF game. We can easily reduce it to the game where \( \mathcal {V}\) and the adversary receive the same \( s' \) from outside (even if maliciously selected). Since symDB is OTDFsecure, the prover passes the protocol with negligible probability. \(\square \)
Theorem 5
If symDB is multiverifier OTMiMsecure and the key agreement protocol with the algorithms \( \mathsf {Gen}_A, \mathsf {Gen}_B,A,B,D \) is DAKA secure then EffpkDB is MiMsecure.
Proof
\( \varGamma _i \) is a game and \( p_i \) denotes the probability that \( \varGamma _i \) succeeds.
\( \varGamma _0: \) The adversary plays the MiM game in EffpkDB with the distinguished verifier \( \mathcal {V}\), \( \mathcal {V}\)’s instances and the prover instances. \( \mathcal {V}\) receives \( \mathsf {pk}_P \) and a given N. We call “matching instance” the instance who sends this N.
\( \varGamma _1: \) We reduce \( \varGamma _0 \) to \( \varGamma _1 \) where no nonce produced by any prover instance is duplicated or equal to any nonce received by any a verifier instance before. Thanks to Lemma 1 in Appendix A, \( p_1  p_0 \) is negligible. So, the matching instance (if any) is unique and sets N before it is sent to \( \mathcal {V}\).
With the reduction from \( \varGamma _1 \) to \( \varGamma _2 \), we show that the secret generated by A and B are indistinguishable from the randomly picked secret. The reduction is showed below:
We define the hybrid games \( \varGamma _{2,t} \) to show \( p_2  p_1 \) is negligible. Here, \( t \in \{0,1,2,...,k\} \) and k is the number of prover instances bounded by a polynomial.
\( \varGamma _{2,i}: \) \( \mathcal {V}\) is simulated as in \( \varGamma _2 \) and the \( j^{th} \) instance of \( \mathsf {P}\) is simulated as in \( \varGamma _2 \) for \( j \le i \) and as in \( \varGamma _1 \) for \( j > i \). Clearly, \( \varGamma _{2,0} = \varGamma _1\) and \( \varGamma _{2, k} = \varGamma _2 \).
Note that if \( b = 0 \) which means \( s_b \) is generated by the oracle B then \( \mathcal {B} \) simulates the game \( \varGamma _{2,i} \). Otherwise, he simulates \( \varGamma _{2,i+1} \).
For the verifier simulation, \( \mathcal {B} \) first checks, if \( (N', .,\mathsf {pk}_P) \) is stored by himself as \( \mathcal {V}\) in \( \varGamma _{2} \). Otherwise, he sends \( (\mathsf {pk}_{P}, N' ) \) to the oracle \( \mathcal {O}_A \) and receives \( s' \). Since \( (N,s_b, \mathsf {pk}_P) \) is always stored in T, (\( \mathsf {pk}_P,N \)) is not queried to \( \mathcal {O}_A \) oracle. In the end of the game, \( \mathcal {A} \) sends his decision. If \( \mathcal {A} \) outputs i, then \( \mathcal {B} \) outputs 0. If \( \mathcal {A} \) outputs \( i + 1 \), then \( \mathcal {B} \) outputs 1. Clearly, the advantage of \( \mathcal {B} \) is \( p_{2,i}  p_{2,i+1} \). Due to the DAKA security, we obtain that \( p_{2,i}  p_{2,i+1} \) is negligible. From the hybrid theorem, we can conclude that \( p_{2,0}  p_{2,k} \) is negligible where \( p_{2,0} = p_1 \) and \( p_{2,k} = p_2\).
\( \varGamma _4: \) We reduce \( \varGamma _3 \) to the multiverifier OTMiMsecurity game \( \varGamma _4 \) where there is only matching instance and the other instances are simulated. With this final reduction, we show that the adversary has to break the multiverifier OTMiMsecurity of symDB in order to break the MiMsecurity of EffpkDB.
The reduction is the following. \( \mathcal {A}^3 \) plays the \( \varGamma _3 \) game. We construct an adversary \( \mathcal {A}^4_i \) in \( \varGamma _4 \). \( \mathcal {A}^4_i \) receives N from the matching prover in \( \varGamma _4 \). \( \mathcal {A}^4_i \) takes \( P_i \) as a matching prover in \( \varGamma _3 \) where \( i \in \{1,...,k\} \). \( \mathcal {A}^4_i \) simulates all of the provers except \( P_i \) against \( \mathcal {A}^3 \). For \( P_i \), \( \mathcal {A}^4_i \) just sends \( (\mathsf {pk}_{P},N) \). In the end, if \( P_i \) is the matching instance in \( \varGamma _3 \) and \( \mathcal {A}^3\) wins then \( \mathcal {A}^4_i \) wins. Therefore \( p_3 \le \sum _i p_{4,i}\) where \( p_{4,i} \) is the probability that \( \mathcal {A}^4_i \) wins. Due to multiverifier OTMiMsecurity, all \( p_{4,i} \)’s are negligible. So, \( p_3 \) is negligible. Hence, \( p_0 \) is negligible. \(\square \)
Theorem 6
If symDB is OTMiMsecure, OTDHsecure and follows the canonical structure and if the key agreement protocol with the algorithms \( \mathsf {Gen}_A, \mathsf {Gen}_B,A,B ,D\) is DAKA secure then EffpkDB is DHsecure.
Proof
\( \varGamma _i \) is a game and \( p_i \) denotes the probability that \( \varGamma _i \) succeeds.
\( \varGamma _0: \) The adversary \( \mathsf {P}\) with its instances plays the DHsecurity game in EffpkDB with the distinguished verifier \( \mathcal {V}\) and its instances and an honest prover \( \mathsf {P}' \). The probability that the adversary succeeds in \( \varGamma _0 \) is \( p_0 \).
\( \varGamma _1 \) and \( \varGamma _2: \) These games are like in the proof of Theorem 5 except that \( \mathsf {P}_j \) is replaced by \( \mathsf {P}'_j \). The reduction from \( \varGamma _0 \) to \( \varGamma _1 \) and \( \varGamma _2 \) is similar to the proof of Theorem 5. So we can conclude that \( p_2  p_0 \) is negligible.
We let N be the nonce produced by the instance of \( \mathsf {P}' \) and \( s_1 \) be its key which is playing a role during the challenge phase of \( \mathcal {V}\) in the DH game.
We reduce \( \varGamma _2 \) to \( \varGamma _3 \) in which all \( \mathsf {Out}_V \) from a verifier instance who receives \( \mathsf {pk}_{P} \) and N is replaced by 0 during the initialization phase. Intuitively, in this case, \( \mathsf {Out}_V \) cannot be equal 1 because if it is 1, it means \( \mathsf {P}' \) impersonates \( \mathsf {P}\). The reduction is as follows: During the initialization game, \( \mathsf {P}' \) sends messages which do not depend on \( s_1 \) because of the canonical structure, and which can be simulated. So, we can reduce this phase to the multiverifier IF game and use Theorem 2 to show that \( p_3 p_2 \) is negligible. This reduction shows that the DHadversary \( \mathsf {P}\) cannot win the game with sending \( \mathsf {pk}_P \) and N generated by \( \mathsf {P}' \).
We reduce \( \varGamma _3 \) to \( \varGamma _4\) where the game stops after the challenge phase for \( \mathcal {V}\). Since the verification phase which is after the challenge phase is noninteractive and \( \mathsf {Out}_V \) is determined at the end of the challenge phase, \( p_4 = p_3\).
We reduce \( \varGamma _4\) to \( \varGamma _5\) which is OTDH game. In \( \varGamma _4\), \( s_1 \) has never been used so s (the key of \( \mathcal {V}\) which is given by the adversary) is independent from \( s_1 \). In this case, \( \mathsf {P}' \) and \( \mathcal {V}\) run symDB with independent secrets. So, \( p_5= p_4 \). Because of the OTDH security of symDB, \( p_5\) is negligible. \(\square \)
5.2 EffpkDB\(^p \)
EffpkDB is not strong private as the public key of the prover is sent in clear. Adding one encryption operation to EffpkDB is enough to have strong privacy.
Assuming that the AKA protocol is DAKA secure and symDB is OTX secure symmetric key DB protocol for all \( X \in \{DF,MiM,DH\} \) and follows canonical structure, we can easily show that EffpkDB\(^p\) is Xsecure from Theorems 4 to 6. To prove this, we start from an adversary playing the Xsecurity game against EffpkDB\(^p \). We construct an adversary playing the same game against EffpkDB to whom we give \( \mathsf {sk}_{V_1} \). The simulation is straightforward.
Theorem 7
Assuming the key agreement protocol is DAKA\(^p \) secure and the cryptosystem is INDCCA secure, then the EffpkDB\(^p \) is strong private in the HPVP model (Definition 5).
Proof
\( \varGamma _i \) is a game and \( p_i \) denotes the probability that \( \varGamma _i \) succeeds.
\( \varGamma _0: \) The adversary \( \mathcal {A} \) plays the HPVP privacy game.
\( \varGamma _1: \) The verifiers skip the decryption when they receive a ciphertext produced by any prover and continue with the values encrypted by the prover. Because of the correctness of the encryption scheme \( p_1 = p_0 \).
This reduction shows that the adversary cannot retrieve \( \mathsf {pk}_P \) and N from the encryption.
We defined the hybrid games \( \varGamma _{3,t} \) to show \( p_3  p_2 \) is negligible. Here, \( t \in \{0,1,2,...,k\} \) and k is the number of prover instances bounded by a polynomial.
\( \varGamma _{3,i}: \) \( \mathcal {V}\) is simulated as in \( \varGamma _3 \) and the \( j^{th} \) instance of \( \mathsf {P}\) is simulated as in \( \varGamma _3 \) if \( j \le i \) and as in \( \varGamma _2 \) if \( j > i \).
\( \mathcal {B} \) assigns \( \mathsf {pk}_V = \mathsf {pk}_A \) and \( \mathsf {pk}_P = \mathsf {pk}_{B_1} \). For all of the prover simulations, if \( j \ne i+1 \), \( P_j \) is simulated normally. \( \mathcal {V}\) is simulated using the \( \mathcal {O}_A \) oracle. Corrupt can be simulated since \( \mathsf {sk}_{B_1} \) is available.
Note that if s is generated from \( B(\mathsf {sk}_{B_0}, \mathsf {pk}_{B_0}, \mathsf {pk}_V,N) \) then \( \mathcal {B} \) simulates \( \varGamma _{3,i+1} \) and if it is generated from \( B(\mathsf {sk}_{B_1}, \mathsf {pk}_{B_1}, \mathsf {pk}_V,N) \) then \( \mathcal {B} \) simulates \( \varGamma _{3,i} \).
For the verifier simulation, \( \mathcal {B} \) first checks if (e, .) is stored by himself as \( \mathcal {V}\) in \( \varGamma _{3} \). Otherwise, he decrypts e and sends \( (\mathsf {pk}_{P_j}, N ) \) to the oracle \( \mathcal {O}_A(\mathsf {pk}_{P},N) \) and receives s. In the end of the game, \( \mathcal {A} \) sends his decision. If \( \mathcal {A} \) outputs i, then \( \mathcal {B} \) outputs 1. If \( \mathcal {A} \) outputs \( i + 1 \), then \( \mathcal {B} \) outputs 0. Clearly, the advantage of \( \mathcal {B} \) is \( p_{3,i}  p_{3,i+1}\) which is negligible because of the DAKA\(^p \) assumption. From the hybrid theorem, we can conclude that \( p_{3,0} \) and \( p_{3,k} \) is negligible where \( p_{3,0} = p_2 \) and \( p_{3,k} = p_3\).
Now, in \( \varGamma _3 \), no identity is used by the provers. Hence, \( \mathcal {A} \) does not have any advantage to guess the prover which means \( p_3 = \frac{1}{2} \). As a result of it, \( p_0 \frac{1}{2} \) is negligible.
Consequently, if we use DAKA secure and DAKA\(^p \) private key agreement protocol in EffpkDB\(^p \), then we have DF, MF, DH secure and strong private publickey DB protocol. For instance, NonceDH key agreement protocol is a good candidate for EffpkDB\(^p \).
The review of the existing publickey DB protocols.
Protocol  Security  Privacy  PK operations  Number of computations 

BrandsChaum [9]  MiM, DF  No Privacy  1 commitment, 1 signature  1 EC multiplication, 2 hashings, 1 mapping, 1 modular inversion, 1 random string selection 
HPO [20]  MiM, DF  Weak Private  4 EC multiplications, 2 random string selections, 2 mappings  
PrivDB [37]  MiM, DF, DH  Strong Private  1 signature, 1 INDCCA encryption  3 EC multiplications, 2 hashings, 2 random string selection, 1 modular inversion, 1 mapping, 1 symmetric key encryption, 1 MAC 
SimppkDB  MiM, DF  No Privacy  1 decryption  1 EC multiplication, 1 hashing, 1 symmetric key decryption, MAC 
EffpkDB  MiM, DF, DH  No privacy  1 DAKA secure KA protocol  1 EC multiplication, 1 hashing, 1 random string selection 
EffpkDB\(^p \)  MiM, DF, DH  Strong Private  1 INDCCA Encryption, 1 DAKA secure KA protocol  3 EC multiplications, 2 hashings, 2 random string selections, 1 symmetric key encryption, 1 MAC 
6 Conclusion
Our main purpose in this work was to design an efficient and a secure publickey DB protocol. First, we designed EffpkDB which is secure against DF, MiM and DH. We did not consider privacy in this one because privacy is not the main concern of some applications. Therefore, EffpkDB can be employed by the applications that do not need privacy. EffpkDB is one of the most efficient public key DB protocols compared to the previous ones (See Table 2).
Second, we added strong privacy to the EffpkDB protocol and obtained EffpkDB\(^p \). We succeeded it by adding one publickey INDCCA secure encryption. In this case, the protocol is not as efficient as before but still one of the most efficient ones with the same security and privacy properties.
In Table 2, we give the security properties of existing publickey DB protocols along with the number of computations done on prover side. We use the number of elliptic curve multiplications and hashing as a metric in our efficiency analysis. We exclude GOR, ProProx and eProProx (in Table 1) since they clearly require a lot more computation than the other publickey DB protocols. In our counting for the number of computations in Table 2, 1 commitment is counted as 1 hashing operation. For the signature, we prefer an efficient and existentially unforgeable under chosenmessage attacks resistant signature scheme ECDSA [21]. ECDSA requires 1 EC multiplication, 1 mapping, 1 hashing, 1 modular inversion and 1 random string selection. For the INDCCA encryption scheme, we use ECIES [31] which requires 2 EC multiplications, 1 KDF, 1 symmetric key encryption, 1 MAC and 1 random string selection. For the DAKA secure key agreement protocol, we use NonceDH which requires 1 EC multiplication, 1 hashing and 1 random string selection.
We first compare the protocols considering the security and the efficiency tradeoff. EffpkDB and SimppkDB are the most efficient ones. However, SimppkDB is secure only against MiM and DF. After EffpkDB, the second most efficient protocol is BrandsChaum protocol [9] but this protocol is only secure against MiM and DF while EffpkDB is secure against DH as well.
Now, we compare the protocols considering security, privacy and efficiency tradeoff. In this case, HPO requires 4 EC multiplications while PrivDB and EffpkDB\(^p \) require 3 EC multiplications and 1 hashing. Hashing is more efficient than elliptic curve multiplication so it looks like PrivDB and EffpkDB\(^p \) are more efficient. However, HPO has an advantage in efficiency if it is used in a dedicated hardware allowing only EC operations. On the other hand, EffpkDB\(^p \) and PrivDB are secure against MiM, DF, DH and strong private while HPO is only MiM and DF secure and only private.
EffpkDB\(^p \) and PrivDB have the same security and privacy properties and almost the same efficiency level. However, if we analyze the efficiency with more metrics, we see that PrivDB requires extra 1 modular inversion and 1 mapping. More importantly, EffpkDB\(^p \) has lighter version EffpkDB which can be used efficiently in the applications which do not need privacy.
One of the important useful property of EffpkDB is that it can employ any DAKA secure key agreement protocol to satisfy DF, MiM and DH security.
Notes
Acknowledgements
This work was partly sponsored by the ICT COST Action IC1403 Cryptacus in the EU Framework Horizon 2020.
Supplementary material
References
 1.EMVCo version 2.6 in book c2 kernel 2 specificationGoogle Scholar
 2.Avoine, G., Bingöl, M.A., Kardaş, S., Lauradoux, C., Martin, B.: A framework for analyzing RFID distance bounding protocols. J. Comput. Secur. 19(2), 289–317 (2011)CrossRefGoogle Scholar
 3.Avoine, G., Tchamkerten, A.: An efficient distance bounding RFID authentication protocol: balancing falseacceptance rate and memory requirement. In: Samarati, P., Yung, M., Martinelli, F., Ardagna, C.A. (eds.) ISC 2009. LNCS, vol. 5735, pp. 250–261. Springer, Heidelberg (2009). doi: 10.1007/9783642044748_21 CrossRefGoogle Scholar
 4.Bengio, S., Brassard, G., Desmedt, Y.G., Goutier, C., Quisquater, J.J.: Secure implementation of identification systems. J. Cryptology 4(3), 175–183 (1991)CrossRefGoogle Scholar
 5.Boureanu, I., Mitrokotsa, A., Vaudenay, S.: Secure and lightweight distancebounding. In: Avoine, G., Kara, O. (eds.) LightSec 2013. LNCS, vol. 8162, pp. 97–113. Springer, Heidelberg (2013). doi: 10.1007/9783642403927_8 CrossRefGoogle Scholar
 6.Boureanu, I., Mitrokotsa, A., Vaudenay, S.: Towards secure distance bounding. In: Moriai, S. (ed.) FSE 2013. LNCS, vol. 8424, pp. 55–67. Springer, Heidelberg (2014). doi: 10.1007/9783662439333_4 Google Scholar
 7.Boureanu, I., Mitrokotsa, A., Vaudenay, S.: Practical and Provably Secure DistanceBounding. IOS Press, Amsterdam (2015)zbMATHCrossRefGoogle Scholar
 8.Boureanu, I., Vaudenay, S.: Optimal proximity proofs. In: Lin, D., Yung, M., Zhou, J. (eds.) Inscrypt 2014. LNCS, vol. 8957, pp. 170–190. Springer, Heidelberg (2015). doi: 10.1007/9783319167459_10 Google Scholar
 9.Brands, S., Chaum, D.: Distancebounding protocols. In: Helleseth, T. (ed.) EUROCRYPT 1993. LNCS, vol. 765, pp. 344–359. Springer, Heidelberg (1994). doi: 10.1007/3540482857_30 Google Scholar
 10.Bussard, L., Bagga, W.: Distancebounding proof of knowledge to avoid realtime attacks. In: Sasaki, R., Qing, S., Okamoto, E., Yoshiura, H. (eds.) SEC 2005. IAICT, vol. 181, pp. 223–238. Springer, Heidelberg (2005). doi: 10.1007/0387256601_15 CrossRefGoogle Scholar
 11.Chothia, T., Garcia, F.D., Ruiter, J., Breekel, J., Thompson, M.: Relay cost bounding for contactless EMV payments. In: Böhme, R., Okamoto, T. (eds.) FC 2015. LNCS, vol. 8975, pp. 189–206. Springer, Heidelberg (2015). doi: 10.1007/9783662478547_11 CrossRefGoogle Scholar
 12.Cremers, C., Rasmussen, K.B., Schmidt, B., Capkun, S.: Distance hijacking attacks on distance bounding protocols. In: SP, pp. 113–127 (2012)Google Scholar
 13.Desmedt, Y.: Major security problems with the unforgeable (Feige) FiatShamir proofs of identity and how to overcome them. In: SECURICOM, pp. 147–159 (1988)Google Scholar
 14.Diffie, W., Hellman, M.E.: New directions in cryptography. IEEE Trans. Inf. Theory 22(6), 644–654 (1976)MathSciNetzbMATHCrossRefGoogle Scholar
 15.Dürholz, U., Fischlin, M., Kasper, M., Onete, C.: A formal approach to distancebounding RFID protocols. In: Lai, X., Zhou, J., Li, H. (eds.) ISC 2011. LNCS, vol. 7001, pp. 47–62. Springer, Heidelberg (2011). doi: 10.1007/9783642248610_4 CrossRefGoogle Scholar
 16.Fischlin, M., Onete, C.: Terrorism in distance bounding: modeling terroristfraud resistance. In: Jacobson, M., Locasto, M., Mohassel, P., SafaviNaini, R. (eds.) ACNS 2013. LNCS, vol. 7954, pp. 414–431. Springer, Heidelberg (2013). doi: 10.1007/9783642389801_26 CrossRefGoogle Scholar
 17.Gambs, S., Onete, C., Robert, J.M.: Prover anonymous and deniable distancebounding authentication. In: ASIA CCS, ACM Symposium, pp. 501–506 (2014)Google Scholar
 18.Hancke, G.P., Kuhn, M.G.: An RFID distance bounding protocol. In: SecureComm 2005, pp. 67–73. IEEE (2005)Google Scholar
 19.Hermans, J., Pashalidis, A., Vercauteren, F., Preneel, B.: A new RFID privacy model. In: Atluri, V., Diaz, C. (eds.) ESORICS 2011. LNCS, vol. 6879, pp. 568–587. Springer, Heidelberg (2011). doi: 10.1007/9783642238222_31 CrossRefGoogle Scholar
 20.Hermans, J., Peeters, R., Onete, C.: Efficient, secure, private distance bounding without key updates. In: WiSec, pp. 207–218 (2013)Google Scholar
 21.Johnson, D., Menezes, A., Vanstone, S.: The elliptic curve digital signature algorithm (ecdsa). Int. J. Inf. Secur. 1(1), 36–63 (2001)CrossRefGoogle Scholar
 22.Kılınç, H., Vaudenay, S.: Comparison of publickey distance bounding protocols, under submissionGoogle Scholar
 23.Kılınç, H., Vaudenay, S.: Optimal proximity proofs revisited. In: Malkin, T., Kolesnikov, V., Lewko, A.B., Polychronakis, M. (eds.) ACNS 2015. LNCS, vol. 9092, pp. 478–494. Springer, Heidelberg (2015). doi: 10.1007/9783319281667_23 CrossRefGoogle Scholar
 24.Kim, C.H., Avoine, G.: RFID distance bounding protocol with mixed challenges to prevent relay attacks. In: Garay, J.A., Miyaji, A., Otsuka, A. (eds.) CANS 2009. LNCS, vol. 5888, pp. 119–133. Springer, Heidelberg (2009). doi: 10.1007/9783642104336_9 CrossRefGoogle Scholar
 25.Kim, C.H., Avoine, G., Koeune, F., Standaert, F.X., Pereira, O.: The swissknife RFID distance bounding protocol. In: Lee, P.J., Cheon, J.H. (eds.) ICISC 2008. LNCS, vol. 5461, pp. 98–115. Springer, Heidelberg (2009). doi: 10.1007/9783642007309_7 CrossRefGoogle Scholar
 26.Krawczyk, H.: HMQV: a highperformance secure DiffieHellman protocol. In: Shoup, V. (ed.) CRYPTO 2005. LNCS, vol. 3621, pp. 546–566. Springer, Heidelberg (2005). doi: 10.1007/11535218_33 CrossRefGoogle Scholar
 27.LaMacchia, B., Lauter, K., Mityagin, A.: Stronger security of authenticated key exchange. In: Susilo, W., Liu, J.K., Mu, Y. (eds.) ProvSec 2007. LNCS, vol. 4784, pp. 1–16. Springer, Heidelberg (2007). doi: 10.1007/9783540756705_1 CrossRefGoogle Scholar
 28.Lauter, K., Mityagin, A.: Security analysis of KEA authenticated key exchange protocol. In: Yung, M., Dodis, Y., Kiayias, A., Malkin, T. (eds.) PKC 2006. LNCS, vol. 3958, pp. 378–394. Springer, Heidelberg (2006). doi: 10.1007/11745853_25 CrossRefGoogle Scholar
 29.Law, L., Menezes, A., Qu, M., Solinas, J., Vanstone, S.: An efficient protocol for authenticated key agreement. Des. Codes Crypt. 28(2), 119–134 (2003)MathSciNetzbMATHCrossRefGoogle Scholar
 30.Okamoto, T., Pointcheval, D.: The gapproblems: a new class of problems for the security of cryptographic schemes. In: Kim, K. (ed.) PKC 2001. LNCS, vol. 1992, pp. 104–118. Springer, Heidelberg (2001). doi: 10.1007/3540445862_8 CrossRefGoogle Scholar
 31.Shoup, V.: A proposal for an ISO standard for public key encryption (2.0) (2001)Google Scholar
 32.Ustaoglu, B.: Obtaining a secure and efficient key agreement protocol from (H)MQV and NAXOS. Des. Codes Crypt. 46(3), 329–342 (2008)MathSciNetzbMATHCrossRefGoogle Scholar
 33.Vaudenay, S.: On privacy models for RFID. In: Kurosawa, K. (ed.) ASIACRYPT 2007. LNCS, vol. 4833, pp. 68–87. Springer, Heidelberg (2007). doi: 10.1007/9783540769002_5 CrossRefGoogle Scholar
 34.Vaudenay, S.: On modeling terrorist frauds. In: Susilo, W., Reyhanitabar, R. (eds.) ProvSec 2013. LNCS, vol. 8209, pp. 1–20. Springer, Heidelberg (2013). doi: 10.1007/9783642412271_1 CrossRefGoogle Scholar
 35.Vaudenay, S.: On privacy for RFID. In: Au, M.H., Miyaji, A. (eds.) ProvSec 2015. LNCS, vol. 9451, pp. 3–20. Springer, Heidelberg (2015). doi: 10.1007/9783319260594_1 Google Scholar
 36.Vaudenay, S.: Privacy failure in the publickey distancebounding protocol. IET Inf. Secur. 10(4), 188–193 (2015)CrossRefGoogle Scholar
 37.Vaudenay, S.: Private and secure publickey distance bounding. In: Böhme, R., Okamoto, T. (eds.) FC 2015. LNCS, vol. 8975, pp. 207–216. Springer, Heidelberg (2015). doi: 10.1007/9783662478547_12 CrossRefGoogle Scholar
 38.Vaudenay, S.: Sound proof of proximity of knowledge. In: Au, M.H., Miyaji, A. (eds.) ProvSec 2015. LNCS, vol. 9451, pp. 105–126. Springer, Heidelberg (2015). doi: 10.1007/9783319260594_6 Google Scholar