WPA2 con chiave precondivisa è un esempio di prova a conoscenza zero?

Quando si imposta un punto di accesso e si seleziona WPA2, è necessario immettere manualmente una chiave precondivisa (una password), PSK, sia nell'AP che nell'STA.

Entrambe le parti, AP e STA, devono autenticarsi a vicenda. Ma devono farlo senza rivelare il PSK. Entrambi devono dimostrare all'altra parte di conoscere il PSK senza inviarlo effettivamente.

È un esempio di prova a conoscenza zero ?

Ho pensato che lo fosse, ma nulla di legittimo si presenta quando cerco google per prova a conoscenza zero e WPA2 o EPA-PSK (il metodo di autenticazione utilizzato).

Nell'autenticazione vi imbattete spesso in password a conoscenza zero (ZKPP). EAP stesso è un framework piuttosto generico e potrebbe comportare la rivelazione dell'identità del client, ad esempio per trasferirlo al livello successivo di autenticazione come RADIUS.

PACE (BSI TR-03110) è un esempio dei protocolli ZKPP utilizzati per l'autenticazione. EAP-SPEKE è un altro.

La sicurezza della chiave si basa sull'uso di sole parti della chiave nello scambio tra client e server. Il client offre un nonce crittografato con la chiave per il server. Pertanto un server non autorizzato riceve un nonce crittografato e mantiene la sua versione in testo normale. Non si tratta di conoscenza zero, poiché in un tempo limitato un server non autorizzato potrebbe accumulare informazioni sufficienti per interrompere la crittografia AES-128.

Quindi EAP-PSK non può essere considerato un esempio di prova della password a conoscenza zero, sebbene altri schemi di autenticazione proposti basati su EAP come EAP-SPEKE abbiano questa proprietà.

Per illustrare la parte problematica del protocollo EAP-PSK, considerare il flusso di messaggi come presentato in RFC 4764.

Il primo messaggio viene inviato dal server al peer a:

  *  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 Il secondo messaggio viene inviato dal peer al server a:

  *  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 Il terzo messaggio viene inviato dal server al peer a:

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

Qui AK è una parte della chiave segreta che viene utilizzata in questa fase e può essere rivelata al server canaglia in grado di decrittografare AES-128.