Auditable PAKEs: Approaching Fair Exchange Without a TTP

Abstract

Roscoe recently showed how HISPs, a class of protocol to allow humans to contribute to the creation of secure authentic channels between them, can be made auditable in the sense that a failed attack on them cannot be disguised as communication failure. In this paper we study the same issue for PAKEs: password authenticated key exchange protocols. We find that because this second style of protocol relies on long term state, it is harder to make them auditable, and that to do so we have to develop new ideas on how to approximate fair exchange without a TTP.

Appendices

Appendix A: a brief survey of PAKEs

Here we briefly describe a number of representative PAKE protocols. This is purely for illustrative purposes; the techniques we describe below should work for all PAKEs. For simplicity we omit various checks that need to be performed. A comprehensive survey of PAKEs can be found in Chap. 40 of the Computer And Information Security Handbook 2nd Edition, Ed J Vacca, Elsevier 2013.

Such protocols come in two phases: key establishment and key confirmation. The first establishes a key based on the shared password, and the second allows each party to confirm that the other knows the password, implying that the key establishment phase was run with the intended party. These phases can generally be chosen independently of each other.

PAKE key establishment

EKE (Encrypted Key Exchange) 

The original EKE, [2], is essentially Diffie-Hellman with the DH terms encrypted with a symmetric key $s^*$ derived from the shared password s using a public, deterministic function f, $s^*=f(s)$:

$$\begin{aligned} \begin{aligned}&A \rightarrow B: \{g^x\}_{s^*}\\&B \rightarrow A: \{g^y\}_{s^*} \\ \end{aligned} \end{aligned}$$

The session key is formed as $K=g^{xy}$.

The original EKE has undergone several fixes to counter flaws, notably the fact that an attacker can eliminate a large number of putative passwords by decrypting the exchanged terms with a guessed password and observing if the resulting plaintext lies in the subgroup.

SPEKE (Simple Password Exponential Key Establishment) 

SPEKE, [6], is essentially a D-H protocol but with the difference that the generator is not fixed and public but rather is computed as an agreed function of the shared secret s, for example:

$$\begin{aligned} h(s):=(H(s))^2 ~~(mod\, p) \end{aligned}$$

The squaring guarantees that g lies in the appropriate subgroup assuming that we are assuming a safe prime p where $p=2q-1$ with q also prime. The protocol is thus essentially a D-H protocol using the shared secret generator.

$$\begin{aligned} \begin{aligned}&A \rightarrow B: h(s)^x \\&B \rightarrow A: h(s)^y \\&K=g(s)^{ab} \end{aligned} \end{aligned}$$

PKK

A rather elegant protocol, PKK due to Boyko et al. [3], is in simplified form for illustration:

$$\begin{aligned} \begin{aligned}&A \rightarrow B: X:=h(s_A) \cdot g^x, \\&B \rightarrow A: Y:= h(s_B) \cdot g^y \\ \end{aligned} \end{aligned}$$

Here h denotes a suitable mapping from the password space to the DH group.

A computes: $K_A:= (Y/h(s_A))^x$

B computes: $K_B:= (X/h(s_B))^y$

J-PAKE 

J-PAKE, [5], uses a quite different approach: the so-called juggling of D-H terms. The original J-PAKE involved both parties generating and transmitting two D-H terms. For simplicity of presentation we describe here a lightweight version, [8], that requires just one D-H term from each party but involves a so-called Common Reference String (CRS) construction.

J-PAKE-CRS 

Here we assume that there is an agreed element h of the group G with unknown log w.r.t. g (in effect a so-called Common Reference String CRS).

$$\begin{aligned} \begin{aligned}&A \rightarrow B: g^x, ZKP(x,g) \\&B \rightarrow A: g^y, ZKP(y,g) \\ \end{aligned} \end{aligned}$$

Round two:

$$\begin{aligned} \begin{aligned}&A \rightarrow B: X:=(h \cdot g^y)^{(x.s)}, ZKP(x.s, h \cdot g^y) \\&B \rightarrow A: Y:=(h \cdot g^x)^{y.s}, ZKP(y.s, h \cdot g^x) \\ \end{aligned} \end{aligned}$$

A computes: $K_A:= (Y/g^{y.x.s})^x$

B computes: $K_B:= (X/g^{x.y.s})^y$

Thus, if $s_A=s_B (=s)$ then $K_A=K_B=h^{x.y.s}$

ZKP(x, y) denotes Zero-Knowledge Proofs of knowledge of a discrete log of x w.r.t. the base y.

Appendix B: Key Derivation and Confirmation

Having established a DH shared secret we typically need to derive a suitable session key for a symmetric algorithm. Various approaches have been proposed and we will not go into the details here but we refer the interested reader to, for example the NIST recommendations, [4], and Krawczyk [7]. A typical approach is to derive the key from the DH value is to use a suitable hash function that yields a close to flat distribution over the key space and include parameters associated with the session:

$$\begin{aligned} \begin{aligned}&SK:=Hash_1(K, A, B) \\ \end{aligned} \end{aligned}$$

Where K is the DH value. Now the parties have to compare their keys, which they might do by, for example, exchanging hashes of the form:

$$\begin{aligned} \begin{aligned}&A \rightarrow B: Hash_2(1, K_A, A, B) \\&B \rightarrow A: Hash_2(2, K_B, A, B ) \end{aligned} \end{aligned}$$

An alternative approach is to segment the derived key into three parts:

$$\begin{aligned} SK=sk||k_A||k_B \end{aligned}$$

Where || denotes concatenation. A and B now exchange the appropriate segments as follows:

$$\begin{aligned} \begin{aligned}&A \rightarrow B: k_A \\&B \rightarrow A: k_B \end{aligned} \end{aligned}$$

A and B now check that the received values agree with those they computed internally. Assuming that they do indeed find agreement they can proceed to use sk as the session key. This may require the calculation of a much larger key than normal, possibly requiring key expansion, see [7].