The SPEKE method relies on exponentiation involving large random numbers modulo a large prime number. The exponentiation operator can be considered a one-way function due to the difficulty of calculating discreet logarithms (the inverse of exponentiation). Each party – the user station and the authenticator – will work from its knowledge of the user’s password p to calculate a common master session key K. To do this, each party generates a large random number. The user station generates the value a, and the authenticator generates the value b. Each party only knows one value; no one ever knows both. The password p, which is known to both the user and the authenticator, is small and easy to remember.

In the discussion below, we consider two parties, the user (or the user’s device) and the authenticator. In wireless networks, the authenticator is the access point (AP). In practice, however, there is often a third party – a backend authentication server which the AP consults. In that case it is the authentication server that actually plays the role of authenticator in the discussion below with the AP acting in a pass-through role. The AP kicks off the EAP conversation by sending an EAP-Identity Request to the user station. The user station replies with the user’s identity as shown in fig. 2. If a backend authentication server is involved, the AP forwards the user’s EAP-Identity Response on to the authentication server in its initial access request. From that point on, the authentication server takes over and conducts the EAP-SPEKE conversation which consists of two more exchanges.

Figure 2

When the authenticator (be it the AP or a backend authentication server) receives the user’s EAP-Identity Response, it looks up the user in its access repository and retrieves the user’s password p. Next, the authenticator creates a large random number b and calculates

B = p^2b mod m

where B is an intermediate value and m is a large prime number used as the modulus. The authenticator sends m and B to the user station in an EAP-SPEKE Request message. The user station creates another large random number “a” and calculates

A = p^2a mod m

Next the user station calculates

K = B^a mod m

where K is the user station’s calculation of the master session key and B is the value received from the authenticator. Finally the user station calculates

Proof_AK = h (“A” | A | K)

where Proof_AK is the proof that A knows K, h is a secure, one-way hash function, “A” is the ASCII string containing a capital A and | is the concatenation operator. The user station now sends an EAP response to the Authenticator containing A and Proof_AK. This EAP Request/Response pair is shown in fig. 3.

Figure 3

When the authenticator receives the response to its first EAP-SPEKE Request, it calculates

K = A^b mod m

where K is the authenticator’s calculation of the master session key and A is the value received from the user. Next the authenticator calculates

Test_AK = h (“A” | A | K)
and
Proof_BK = h (“B” | B | K)

Now the authenticator compares Test_AK to the value Proof_AK received from the user station. If they are not equal, the authenticator signals failure. If they are equal, the authenticator sends a second EAP-SPEKE Request to the user station as shown in fig. 4.

Figure 4

When the user station receives the second EAP-SPEKE Request, it calculates

Test_BK = h (“B” | B | K)

from values received or calculated earlier. The user station compares Test_BK to the value Proof_BK received from the authenticator. If they are not equal, the user station aborts the attempted session. If they are equal, the user station returns an empty EAP-SPEKE Response to the authenticator to signal that it is satisfied with the authentication.

When the authenticator receives the empty response, it returns an EAP Success message to the user station as a final signal that the authentication succeeded.

Note that the session key K is independently calculated by each party. This works due to the associative property of exponentiation. It is computationally infeasible for an attacker to work backward from the values A or B to calculate p due to the difficulty of calculating discrete logarithms, the inverse function to exponentiation. Note also that if p is compromised, an attacker listening in on an authentication between the user and the authenticator is still unable to calculate K. To calculate K he would need to know the values of both a and b which are very large random numbers. Neither can the attacker work backward from Proof_AK or Proof_BK to calculate K because h is a one-way hash function. This inability to calculate K even if p is known is what gives SPEKE the property of forward secrecy defined.

The master session key K itself is not used as a WEP or TKIP key to encrypt the wireless data session being established. Those keys are derived from K using a key derivation function.