On Password-Authenticated Key Exchange Security Modeling

Abstract

Deciding which security model is the right one for Authenticated Key Exchange (AKE) is well-known to be a difficult problem. In this paper, we examine definitions of security for Password-AKE (PAKE) in the style proposed by Bellare et al. [5] at Eurocrypt 2000. Indeed, there does not seem to be any consensus, even when narrowing the study down to this particular authentication method and model style, on how to precisely define fundamental notions such as accepting, terminating, and partnering. The aim of this paper is to begin addressing this problem. We first show how definitions vary from paper to paper. We then propose and thoroughly motivate a definition of our own, and use the opportunity to correct a minor flaw in a more recent and more PAKE-appropriate model proposed by Abdalla et al. [3] at Public Key Cryptography 2005. Finally, we argue that the uniqueness of partners holding with overwhelming probability ought to be an explicitly required and proven property for AKE in general, but even more so in the password case, where the optimal security bound one aims to achieve is no longer a negligible value. To drive this last point, we exhibit a protocol that is provably secure following the Abdalla et al. definition, and at the same time fails to satisfy this property.

A BPR-style Models Revisited

This appendix is just a formal recap of our complete list of requirements.

Principals and Instances. An interactive game, indexed by the security parameter $\lambda \in \mathbb {N}$, is played between a challenger ${\mathcal {CH}}$ and an adversary ${\mathcal {A}}$. All of the algorithms considered are Probabilistic, Polynomial-Time (PPT) in $\lambda$.

At the beginning of the game, there is a fixed set of principals (or users), partitioned into non-empty sets of clients ${\mathcal {C}}$ and servers ${\mathcal {S}}$. Each client ${\mathcal {C}}$ is assigned a password $pw_{\mathcal {C}}$ drawn uniformly at random from some finite set $\mathsf {PW}$ of bitstrings. Each server ${\mathcal {S}}$ holds the full set of all clients’ passwords $\{pw_{\mathcal {C}}\}_{\mathcal {C}}$.

Adversary ${\mathcal {A}}$ has oracle access - via the queries described below - to any number of instances ${\mathcal {U}}^i$ ($i\in \mathbb {N}$) of any principal ${\mathcal {U}}$. An instance of ${\mathcal {U}}^i$ represents an attempt ${\mathcal {U}}$ makes at running the PAKE protocol over the network fully controlled by ${\mathcal {A}}$. An instance’s objective is to compute a Session Key (or SK) it believes it shares with an instance ${\mathcal {V}}^j$ of some other principal ${\mathcal {V}}$. This should happen only if ${\mathcal {U}}^i$ thinks it is partnered (see below) to ${\mathcal {V}}^j$.

At any point in time, an instance ${\mathcal {U}}^i$ may terminate (see below). By this time, ${\mathcal {U}}^i$ should have computed (1) a Partner Identity (or PID) $pid_{\mathcal {U}}^i$, a (2) Session Identity (SID) $sid_{\mathcal {U}}^i$, and (3) a SK $sk_{\mathcal {U}}^i$. The PID is a bitstring indicating the identity of the instance with which ${\mathcal {U}}^i$ believes it has communicated with. The SID is a bitstring serving as an identifier for both the key exchange run that just occurred, and the session in which the computed SK will subsequently serve. Often the SID is always in practice set to being the ordered concatenation of all exchanged protocol messages, except possibly the last message. At any point in time an instance may also abort (see below), with no SK. Once an instance has halted (see below) it can no longer be reused.

Status of Instances and Partnering.

Halting. An instance halts if it stops sending and receiving messages, and ceases to compute anything. Halting can be “good” (i.e. with a SK) or “bad” (i.e. without a SK).

Accepting. An instance ${\mathcal {U}}^i$ accepts if and only if $sid_{\mathcal {U}}^i$ is set to a non-$\varepsilon$ value. Accepting means that ${\mathcal {U}}^i$ believes it is holding enough information to compute a SK.

Terminating. An instance ${\mathcal {U}}^i$ terminates if and only if $sk_{\mathcal {U}}^i$ is set to a non-$\varepsilon$ value. If an instance terminates, it halts. Terminating means ${\mathcal {U}}$ believes it holds a good SK, and is now willing to use it in higher-level applications. ${\mathcal {U}}^i$ will no longer send nor receive PAKE protocol messages. If an instance terminates, it accepts, or has previously accepted. In both cases, $sid_{\mathcal {U}}^i$ is set to a non-$\varepsilon$ value and remains so.

Aborting. An instance ${\mathcal {U}}^i$ aborts if it halts without having terminated.

Semi-partnering. ${\mathcal {U}}^i$ and ${\mathcal {V}}^j$ are semi-partnered if (1) one is a client and one is a server, (2) $pid_{\mathcal {U}}^i={\mathcal {V}}$ and $pid_{\mathcal {V}}^j={\mathcal {U}}$, (3) $sid_{\mathcal {U}}^i\ne \varepsilon$, $sid_{\mathcal {V}}^j\ne \varepsilon$, and $sid_{\mathcal {U}}^i=sid_{\mathcal {V}}^j$.

Partnering. ${\mathcal {U}}^i$ and ${\mathcal {V}}^j$ are partnered if (1) they are semi-partnered and (2) $sk_{\mathcal {U}}^i\ne \varepsilon$, $sk_{\mathcal {V}}^j\ne \varepsilon$, and $sk_{\mathcal {U}}^i=sk_{\mathcal {V}}^j$. So, if an instance is semi-partnered to another, it has accepted, and holds a SID. If it is partnered to another, it has terminated and holds a SK.

Partnering Graph. A partnering graph is a graph with instances for nodes. Two nodes have an edge if and only if the corresponding instances are partners.

Correctness. If ${\mathcal {C}}^i$ with $pid_{\mathcal {C}}^i={\mathcal {S}}$ and ${\mathcal {S}}^j$ with $pid_{\mathcal {S}}^j={\mathcal {C}}$ run the protocol fully and correctly, ${\mathcal {C}}^i$ and ${\mathcal {S}}^j$ are partnered.

Find-then-Guess.

• $\mathsf {send}({\mathcal {U}},i,m)$: ${\mathcal {A}}$ has message m delivered to ${\mathcal {U}}^i$. ${\mathcal {U}}^i$ processes the message according to protocol specification. To instruct an instance ${\mathcal {U}}$ to send the first protocol message to entity ${\mathcal {V}}$, ${\mathcal {A}}$ makes the query with $M={\mathcal {V}}$. This query is used to model arbitrary message delivery to an instance. In particular, it serves to count impersonation attacks.

• $\mathsf {execute}({\mathcal {U}},{\mathcal {V}},i,j)$: The protocol is executed faithfully and completely between ${\mathcal {U}}^i$ and ${\mathcal {V}}^j$ and the resulting transcript is given to ${\mathcal {A}}$. ${\mathcal {A}}$ thus gets to see as many honest protocol runs as it wishes.

• $\mathsf {reveal}({\mathcal {U}},i)$: If ${\mathcal {U}}^i$ has not terminated or if it is part of a partnering graph in which an instance has been tested, the query returns $\bot$. Otherwise, it returns $sk_{\mathcal {U}}^i$ to ${\mathcal {A}}$.

• $\mathsf {test}({\mathcal {U}},i)$: $\mathsf {test}({\mathcal {U}},i)$: If ${\mathcal {U}}^i$ has not terminated or is not fresh, this returns $\bot$. Otherwise, ${\mathcal {CH}}$ flips a coin b outside of ${\mathcal {A}}$’s view. If $b=0$, a random string R is drawn from the session key space and $tk_{\mathcal {U}}^i\leftarrow R$. Otherwise, $tk_{\mathcal {U}}^i\leftarrow sk_{\mathcal {U}}^i$. $tk_{\mathcal {U}}^i$ is then returned to ${\mathcal {A}}$. The $\mathsf {test}$ query may only be used once in the game.

Eventually, ${\mathcal {A}}$ halts the overall game, at which point it outputs a bit $b'$. If the game was halted without ${\mathcal {A}}$ making any $\mathsf {test}$ query, then ${\mathcal {CH}}$ privately flips a coin b.

Freshness: An instance ${\mathcal {U}}^i$ is said to be fresh if it is in a partnering graph in which no instance has been the target of a reveal query.

Real-or-Random. The $\mathsf {send}$ and $\mathsf {execute}$ queries are identical to those in the FtG model. However, the $\mathsf {reveal}$ query is no longer available. Instead, it is replaced by as many $\mathsf {test}$ queries as ${\mathcal {A}}$ wants. How they are answered depends on the value of a bit b flipped by ${\mathcal {CH}}$ outside of ${\mathcal {A}}$’s view at the beginning of the game.

• $\mathsf {test}({\mathcal {U}},i)$: If ${\mathcal {U}}^i$ has not terminated, $\bot$ is returned. Otherwise, suppose first that $b=0$. If ${\mathcal {U}}^i$ is not partnered to any instance, or no instance in the partnering graph it is a part of was subjected to a $\mathsf {test}$ query, ${\mathcal {CH}}$ selects a random R from the session key space and sets $tk_{\mathcal {U}}^i\leftarrow R$. If ${\mathcal {U}}^i$ is within a partnering graph where some instance ${\mathcal {V}}^j$ that has been tested, ${\mathcal {CH}}$ sets $tk_{\mathcal {U}}^i\leftarrow tk_{\mathcal {V}}^j$. Suppose now that $b=1$. In this case, ${\mathcal {CH}}$ sets $tk_{\mathcal {U}}^i\leftarrow sk_{\mathcal {U}}^i$. Then, ${\mathcal {A}}$ receives $tk_{\mathcal {U}}^i$.

The slight complication arising in case $b=0$ is that even if the SKs assigned are random, they must at least remain consistent across instances that should hold the same keys. As in FtG, at any point in time ${\mathcal {A}}$ may halt the game and output a bit $b'$.

Technically Defining Security. In both FtG and RoR, one usually considers three security properties: SK security, Client-to-Server (C2S) authentication, and Server-to-Client (S2C) authentication. We explicitly add to this uniqueness of partners by requiring that SIDs are shared by at most two instances (SID).

SK security: Let $\mathsf {S}$ be the event that “$b'=b$ at the end of the game”. ${\mathcal {A}}$’s natural advantage is defined to be $\mathsf {Adv}^s({\mathcal {A}}):=2\mathsf {Pr}[\mathsf {S}]-1$. A PAKE protocol is said to have semantically secure SKs if there exists a non-zero constant $C\in \mathbb {N}$ such that for any PPT ${\mathcal {A}}$, there exists a negligible (in $\lambda$) function $\mathsf {negl}$ with the property that $\mathsf {Adv}^s({\mathcal {A}})\le \frac{Cn_{se}}{|\mathsf {PW}|}+\mathsf {negl}(\lambda )$ where $n_{se}$ is an upper bound on the number of $\mathsf {send}$ queries the adversary makes.

Authentication: Let $\mathsf {C2S}$ be the event that “there exists some server instance ${\mathcal {S}}^j$ that is ready to use a SK, but has not had a correct exchange with a client instance”. Here we simply set $\mathsf {Adv}^{c2s}({\mathcal {A}}):=\mathsf {Pr}[\mathsf {C2S}]$, and we say that a PAKE achieves client-to-server authentication if there exists a non-zero C such that for any PPT ${\mathcal {A}}$, there exists a negligible function $\mathsf {negl}$ with the property that $\mathsf {Adv}^{c2s}({\mathcal {A}})\le \frac{Cn_{se}}{|\mathsf {PW}|}+\mathsf {negl}(\lambda )$. Server-to-client authentication is defined similarly.

Partner Uniqueness: Let $\mathsf {SID}$ be the event that “there exists more than two instances that have the same non-$\varepsilon$ SID”. Let $\mathsf {Adv}^{sid}({\mathcal {A}}):=\mathsf {Pr}[\mathsf {SID}]$. We say that PAKE achieves unique partnering if for any PPT ${\mathcal {A}}$ the function $\mathsf {Adv}^{sid}$ is negligible.