Wireless-Channel Key Exchange

Abstract

Wireless-channel key exchange (WiKE) protocols that leverage Physical Layer Security (PLS) techniques could become an alternative solution for secure communication establishment, such as vehicular ad-hoc networks, wireless IoT networks, or cross-layer protocols.

In this paper, we provide a novel abstraction of WiKE protocols and present the first game-based security model for WiKE. Our result enables the analysis of security guarantees offered by these cross-layer protocols and allows the study of WiKE’s compositional aspects. Further, we address the potential problem of the slow-rate secret-key generation in WiKE due to inadequate environmental conditions that might render WiKE protocols impractical or undesirably slow. We explore a solution to such a problem by bootstrapping a low-entropy key coming as the output of WiKE using a Password Authenticated Key Exchange (PAKE). On top of the new security definition for WiKE and those which are well-established for PAKE, we build a compositional WiKE-then-PAKE model and define the minimum security requirements for the safe sequential composition of the two primitives in a black-box manner. Finally, we show the pitfalls of previous ad-hoc attempts to combine WiKE and PAKE.

Security Model for PAKE

Today, the Real-or-Random (RoR) model from [3] and the Universally Composable PAKE model from [14] are considered state-of-the-art models rigorously capturing PAKE security requirements. In this paper, we will use a variant of the RoR definition from [3], where $\textsf{Reveal}$ is added. $\textsf{Reveal}$ query was available in the original Find-then-Guess model and removed later from the RoR because it can be simulated via $\textsf{Test}$ oracle, which in the RoR model can be queried multiple times. However, having a $\textsf{Reveal}$ oracle facilitates proof reductions that rely on the security of PAKE and was later adopted by multiple authors [2, 35].

1.1 PAKE Protocol

We represent PAKE protocol as a pair of algorithms $(\textsf{PGen},\textsf{P})$. $\textsf{PGen}$ is a password generation algorithm, while $\textsf{P}$ defines the execution of the PAKE protocol. $\textsf{PGen}$ samples passwords uniformly at random from the dictionary $\mathbb {D}_{pw}$. We assume that $\textsf{P}$ describes several sub-algorithms, one of which is responsible for the generation of public parameters, common to all principals.

1.2 Real-or-Random Security Model for PAKE

Let us denote a game that represents the RoR security model $G^{pake}$. For such a game, there exists a challenger $\mathcal {C}^{pake}$ that will keep the appropriate secret information away from an adversary $\mathcal {A}$ while administrating the security experiment. We denote the security parameter by $\lambda \in \mathbb {N}$.

Participants and Passwords. For the two-party PAKE scenario, each principal U, identified by a string, comes either from a client set $\mathbb {C}$ or a server set $\mathbb {S}$, which are finite, disjoint, nonempty sets. We denote the union of $\mathbb {C}$ and $\mathbb {S}$ sets as $\mathbb {I}_{pake}$. As usual, we assume that each client $C \in \mathbb {C}$ possesses a password $C.\textsf{pw}$, while each server $S \in \mathbb {S}$ holds a vector of the passwords of all clients $S.\textsf{PW} := {\langle C.\textsf{pw} \rangle }_{C \in \mathbb {C}}$. We assume that these passwords are sampled independently and uniformly from $\mathbb {D}_{pw}$ at the start of $G^{ror}$.

Protocol Execution. The protocol $\textsf{P}$ is a PPT algorithm that describes the reaction of principals to incoming messages. In our model, we allow each principal to run an unlimited number of instances to model real-world parallel executions of $\textsf{P}$. We denote $U^i$ the i-th instance of principal U. In places that matters, we will denote initiator instances $C^i$ and responder instances $S^j$.

Full Network Adversary. When analyzing the security of $\textsf{P}$, we assume that our adversary $\mathcal {A}$ has complete network control. $\mathcal {A}$ has access to principals’ instances via $\textsf{Execute}$($C^i, S^j$), $\textsf{Send}$($U^i, M$), $\textsf{Reveal}$($U^i$), and $\textsf{Test}$($U^i$) queries provided by $\mathcal {C}^{pake}$. These are standard RoR PAKE model queries as described in [3, 6] that $\mathcal {A}$ may ask multiple times (even $\textsf{Test}$ queries).

Initialization and Internal State. The challenger $\mathcal {C}^{pake}$ maintains execution state and game state in order to run a sound simulation. In an initialization phase, public parameters and the internal state are fixed. The appropriate sub-algorithm of $\textsf{P}$, called $\textsf{PGen}$, is run to generate the system’s public parameters. From the adversary’s perspective, an instance $C^i$ comes into being after $\textsf{Send}$($C^i$, S) query is asked. For each client a secret $C.\textsf{pw}$ is drawn uniformly and independently at random from a finite set $\mathbb {D}_{pw}$ of size $|\mathbb {D}_{pw}|$.

Partnering. We say that instance $C^i$ is a partner instance to $S^j$ and vice versa if: (1) C is a client and S is a server or vice versa, (2) $\textsf{sid} := C^i.\textsf{sid} = S^j.\textsf{sid} \ne \bot$, (3) $C^i.\textsf{pid} = S$ and $S^j.\textsf{pid} = C$, (4) $C^i.\textsf{key} = S^j.\textsf{key}$, and (5) no other instance has a non-$\bot$ session identity equal to $\textsf{sid}$.

Freshness. An instance becomes fresh once it accepts (with or without a partner). An instance $U^i$ then becomes unfresh if any of the following events occurs: (1) $\textsf{Reveal}$($U^i$) query is asked, (2) if $\textsf{Reveal}$($V^j$) query is asked and $V^j$ is $U^i$’s partner instance.

PAKE Security. Now we can formally define RoR PAKE advantage of $\mathcal {A}$ against $\textsf{P}$. At some point in time, $\mathcal {A}$ will end $G^{pake}$ and outputs a bit $b'$. We say that $\mathcal {A}$ wins and breaks the RoR security of $\textsf{P}$ if $b' = b$ (b being the hidden bit selected at the beginning of $G^{pake}$. The probability of this event is denoted by $\textsf{Pr}[b'= b]$. The pake-advantage of $\mathcal {A}$ in breaking $\textsf{P}$ is defined as

$$\begin{aligned} Adv^{pake}_{\textsf{P}}(\mathcal {A}) \ \mathrel {{\mathop {=}\limits ^{{\text{ def }}}}}\ \left| 2 \cdot \textsf{Pr}[b = b'] - 1\right| . \end{aligned}$$

(10)

Finally, we say that $\textsf{P}$ is pake-secure if there exists a positive constant B such that for every PPT adversary $\mathcal {A}$ it holds that

$$\begin{aligned} Adv^{pake}_\textsf{P}(\mathcal {A}) \le \frac{B\cdot n_{se}}{|\mathbb {D}_{pw}|} + \epsilon (\lambda ), \end{aligned}$$

(11)

where $n_{se}$ is an upper bound on the number of $\textsf{Send}$ queries $\mathcal {A}$ makes, $|\mathbb {D}_{pw}|$ is the cardinality of $\mathbb {D}_{pw}$, and function $\epsilon$ is negligible in the security parameter $\lambda$. Moreover, passwords are assigned uniformly at random to clients.