Czy WPA2 z kluczem wstępnym jest przykładem dowodu braku wiedzy?

Podczas konfigurowania punktu dostępu i wybierania WPA2 należy ręcznie wprowadzić klucz współdzielony (hasło), PSK, zarówno do AP, jak i STA.

Obie strony, AP i STA, muszą się uwierzytelnić. Ale muszą to zrobić bez ujawnienia PSK. Obaj muszą udowodnić drugiej stronie, że znają PSK, nie wysyłając go.

Czy to przykład dowodu braku wiedzy ?

Myślałem, że tak, ale nic nie pojawia się, gdy szukam w Google dowodów zerowej wiedzy i WPA2 lub EPA-PSK (stosowana metoda uwierzytelniania).

Podczas uwierzytelniania często dochodzi do potwierdzenia hasła zerową wiedzą (ZKPP). Sam protokół EAP jest raczej ogólną strukturą i może obejmować ujawnianie tożsamości klienta, na przykład w celu przeniesienia go do kolejnej warstwy uwierzytelniania, takiej jak RADIUS.

PACE (BSI TR-03110) to jeden przykład protokołów ZKPP używanych do uwierzytelniania. EAP-SPEKE to kolejny.

Bezpieczeństwo klucza polega na użyciu tylko części klucza w wymianie między klientem a serwerem. Klient oferuje kod zaszyfrowany kluczem do serwera. Dlatego nieuczciwy serwer odbiera zaszyfrowaną wartość jednorazową i zachowuje swoją wersję zwykłego tekstu. Nie jest to wiedza zerowa, ponieważ w nieokreślonym czasie nieuczciwy serwer może zgromadzić wystarczającą ilość informacji, aby przerwać szyfrowanie AES-128.

Dlatego EAP-PSK nie może być uważany za przykład sprawdzania hasła przy użyciu zerowej wiedzy, chociaż inne proponowane schematy uwierzytelniania oparte na EAP, takie jak EAP-SPEKE, mają tę właściwość.

Aby zilustrować problematyczną część protokołu EAP-PSK, rozważ przepływ komunikatów, jak przedstawiono w RFC 4764.

Pierwsza wiadomość jest wysyłana przez serwer do peera na:

  *  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 Druga wiadomość jest wysyłana przez partnera do serwera w celu:

  *  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 Trzecia wiadomość jest wysyłana przez serwer do peera na:

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

Tutaj AK jest częścią tajnego klucza, który jest używany na tym etapie i może zostać ujawniony nieuczciwemu serwerowi, który jest w stanie odszyfrować AES-128.