Ist WPA2 mit vorinstalliertem Schlüssel ein Beispiel für einen wissensfreien Beweis?

Wenn Sie einen Zugangspunkt einrichten und WPA2 auswählen, müssen Sie einen vorinstallierten Schlüssel (ein Kennwort), PSK, sowohl in den AP als auch in die STA manuell eingeben.

Beide Parteien, AP und STA, müssen sich gegenseitig authentifizieren. Aber sie müssen dies tun, ohne die PSK preiszugeben. Beide müssen der anderen Partei beweisen, dass sie die PSK kennen, ohne sie tatsächlich zu senden.

Ist das ein Beispiel für einen wissensfreien Beweis ?

Ich dachte, es wäre so, aber es zeigt sich nichts Legitimes, wenn ich nach wissensfreien Beweisen und WPA2 oder EPA-PSK (der verwendeten Authentifizierungsmethode) google.

Bei der Authentifizierung stoßen Sie häufig auf einen wissensfreien Passwortnachweis (ZKPP). EAP selbst ist ein eher allgemeines Framework und kann die Offenlegung der Identität des Clients beinhalten, um es beispielsweise auf die nächste Authentifizierungsebene wie RADIUS zu übertragen.

PACE (BSI TR-03110) ist ein Beispiel für ZKPP-Protokolle, die zur Authentifizierung verwendet werden. EAP-SPEKE ist eine andere.

Die Sicherheit des Schlüssels beruht auf der Verwendung nur von Teilen des Schlüssels beim Austausch zwischen dem Client und dem Server. Der Client bietet dem Server eine mit dem Schlüssel verschlüsselte Nonce an. Daher empfängt ein Rogue-Server eine verschlüsselte Nonce und behält seine Klartextversion. Dies ist kein Nullwissen, da ein betrügerischer Server in einer begrenzten Zeit möglicherweise genügend Informationen sammelt, um die AES-128-Verschlüsselung zu unterbrechen.

Daher kann EAP-PSK nicht als Beispiel für einen Kennwortnachweis ohne Wissen angesehen werden, obwohl andere vorgeschlagene Authentifizierungsschemata, die auf EAP basieren, wie EAP-SPEKE, diese Eigenschaft haben.

Um den problematischen Teil des EAP-PSK-Protokolls zu veranschaulichen, betrachten Sie den Nachrichtenfluss wie in RFC 4764 dargestellt.

Die erste Nachricht wird vom Server an den Peer gesendet an:

  *  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 Die zweite Nachricht wird vom Peer an den Server gesendet an:

  *  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 Die dritte Nachricht wird vom Server an den Peer gesendet an:

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

Hier ist AK ein Teil des geheimen Schlüssels, der in dieser Phase verwendet wird und möglicherweise dem betrügerischen Server offengelegt wird, der AES-128 entschlüsseln kann.