¿Es WPA2 con clave precompartida un ejemplo de prueba de conocimiento cero?

Al configurar un punto de acceso y seleccionar WPA2, uno debe ingresar manualmente una clave precompartida (una contraseña), PSK, tanto en el AP como en la STA.

Ambas partes, AP y STA, deben autenticarse mutuamente. Pero tienen que hacerlo sin revelar el PSK. Ambos tienen que demostrar a la otra parte que conocen el PSK sin enviarlo realmente.

¿Es ese un ejemplo de una prueba de conocimiento cero ?

Pensé que era, pero no aparece nada legítimo cuando busco en Google para prueba de conocimiento cero y WPA2 o EPA-PSK (el método de autenticación utilizado).

En la autenticación, a menudo se encuentra con la prueba de contraseña de conocimiento cero (ZKPP). EAP en sí mismo es un marco bastante genérico y podría implicar revelar la identidad del cliente, por ejemplo, transferirlo a la siguiente capa de autenticación, como RADIUS.

PACE (BSI TR-03110) es un ejemplo de los protocolos ZKPP utilizados para la autenticación. EAP-SPEKE es otro.

La seguridad de la clave se basa en el uso de solo partes de la clave en el intercambio entre el cliente y el servidor. El cliente ofrece un nonce cifrado con la clave del servidor. Por lo tanto, un servidor fraudulento recibe un nonce cifrado y mantiene su versión de texto plano. Esto no es conocimiento cero, ya que en un tiempo finito un servidor no autorizado podría acumular suficiente información para romper el cifrado AES-128.

Por lo tanto, EAP-PSK puede no considerarse un ejemplo de prueba de contraseña de conocimiento cero, aunque otros esquemas de autenticación propuestos basados ​​en EAP como EAP-SPEKE tienen esta propiedad.

Para ilustrar la parte problemática del protocolo EAP-PSK, considere el flujo de mensajes tal como se presenta en RFC 4764.

El primer mensaje es enviado por el servidor al igual para:

  *  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 El segundo mensaje es enviado por el par al servidor para:

  *  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 El tercer mensaje es enviado por el servidor al igual para:

  *  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)

Aquí AK es parte de la clave secreta que se usa en esta etapa y puede revelarse al servidor no autorizado que puede descifrar AES-128.