9
$\begingroup$

When setting up an access point and selecting WPA2, one must manually enter a pre-shared key (a password), PSK, into both the AP and the STA.

Both parties, AP and STA, must authenticate each other. But they have to do so without revealing the PSK. Both have to proof to the other party that they know the PSK without actually sending it.

Is that an example of a zero-knowledge proof?

I thought it was, but nothing legit shows up when I google for zero-knowledge proof and WPA2 or EPA-PSK (the authentication method used).

$\endgroup$

migrated from security.stackexchange.com May 5 '12 at 23:32

This question came from our site for information security professionals.

6
$\begingroup$

In authentication you often come accross zero-knowledge password proof (ZKPP). EAP itself is a rather generic framework and it might involve revealing the identity of the client for instance to transfer it to the next layer of authentication such as RADIUS.

PACE (BSI TR-03110) is one example of ZKPP protocols used for authentication. EAP-SPEKE is another.

The security of the key relies on the use of only parts of the key in the exchange between the client and the server. The client offers a nonce encrypted with the key to the server. Therefore a rogue server receives a encrypted nonce and holds its plaintext version. This is not zero-knowledge, since in a finite time a rogue server might accumulate enough information to break the AES-128 encryption.

Hence EAP-PSK may not be considered an example of zero-knowledge password proof, though other proposed authentication schemes based on EAP such as EAP-SPEKE have this property.

To illustrate the problematic part of the EAP-PSK protocol consider the message flow as presented in RFC 4764.

The first message is sent by the server to the peer to:

  *  Send a 16-byte random challenge (RAND_S).  RAND_S was called RA
     in Section 3.2

  *  State its identity (ID_S).  ID_S was denoted by A in
     Section 3.2.

o The second message is sent by the peer to the server to:

  *  Send another 16-byte random challenge (RAND_P).  RAND_P was
     called RB in Section 3.2

  *  State its identity (ID_P).  ID_P was denoted by B in
     Section 3.2.

  *  Authenticate to the server by proving that it is able to
     compute a particular MAC (MAC_P), which is a function of the
     two challenges and AK:
     MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)

o The third message is sent by the server to the peer to:

  *  Authenticate to the peer by proving that it is able to compute
     another MAC (MAC_S), which is a function of the peer's
     challenge and AK:
     MAC_S = CMAC-AES-128(AK, ID_S||RAND_P)

Here AK is a part of the secret key that is used at this stage and may be revealed to the rogue server that is able to decrypt AES-128.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy