O WPA2 com chave pré-compartilhada é um exemplo de prova de zero conhecimento?

Ao configurar um ponto de acesso e selecionar WPA2, é necessário inserir manualmente uma chave pré-compartilhada (uma senha), PSK, no AP e no STA.

Ambas as partes, AP e STA, devem se autenticar. Mas eles precisam fazer isso sem revelar o PSK. Ambos têm que provar à outra parte que conhecem o PSK sem realmente enviá-lo.

Isso é um exemplo de prova de zero conhecimento ?

Eu pensei que era, mas nada de legítimo aparece quando eu pesquiso no Google à prova de zero conhecimento e WPA2 ou EPA-PSK (o método de autenticação usado).

Na autenticação, você geralmente encontra ZKPP (prova de senha de conhecimento zero). O próprio EAP é uma estrutura bastante genérica e pode envolver a revelação da identidade do cliente, por exemplo, para transferi-lo para a próxima camada de autenticação, como o RADIUS.

PACE (BSI TR-03110) é um exemplo de protocolo ZKPP usado para autenticação. EAP-SPEKE é outro.

A segurança da chave depende do uso de apenas partes da chave na troca entre o cliente e o servidor. O cliente oferece um nonce criptografado com a chave para o servidor. Portanto, um servidor não autorizado recebe um nonce criptografado e mantém sua versão em texto sem formatação. Isso não é de conhecimento zero, pois em um tempo finito um servidor não autorizado pode acumular informações suficientes para interromper a criptografia AES-128.

Portanto, o EAP-PSK pode não ser considerado um exemplo de prova de senha de conhecimento zero, embora outros esquemas de autenticação propostos baseados no EAP, como o EAP-SPEKE, possuam essa propriedade.

Para ilustrar a parte problemática do protocolo EAP-PSK, considere o fluxo de mensagens conforme apresentado na RFC 4764.

A primeira mensagem é enviada pelo servidor ao par 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 A segunda mensagem é enviada pelo ponto ao 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 A terceira mensagem é enviada pelo servidor ao par 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)

Aqui, AK faz parte da chave secreta usada neste estágio e pode ser revelada ao servidor não autorizado que é capaz de descriptografar o AES-128.