WPA2 avec clé pré-partagée est-il un exemple de preuve de connaissance zéro?

Lors de la configuration d'un point d'accès et de la sélection de WPA2, il faut saisir manuellement une clé pré-partagée (un mot de passe), PSK, dans l'AP et le STA.

Les deux parties, AP et STA, doivent s'authentifier mutuellement. Mais ils doivent le faire sans révéler le PSK. Les deux doivent prouver à l'autre partie qu'ils connaissent le PSK sans l'envoyer réellement.

Est-ce un exemple de preuve de connaissance zéro ?

Je pensais que c'était le cas, mais rien de légitime n'apparaît lorsque je recherche Google pour une preuve de connaissance zéro et WPA2 ou EPA-PSK (la méthode d'authentification utilisée).

Dans l'authentification, vous rencontrez souvent une preuve de mot de passe sans connaissance (ZKPP). EAP lui-même est un cadre plutôt générique et il peut impliquer de révéler l'identité du client, par exemple pour le transférer vers la couche d'authentification suivante telle que RADIUS.

PACE (BSI TR-03110) est un exemple de protocoles ZKPP utilisés pour l'authentification. EAP-SPEKE en est un autre.

La sécurité de la clé repose sur l'utilisation de seulement des parties de la clé dans l'échange entre le client et le serveur. Le client propose un nonce chiffré avec la clé du serveur. Par conséquent, un serveur non autorisé reçoit un nonce chiffré et conserve sa version en texte brut. Ce n'est pas une connaissance nulle, car dans un temps limité, un serveur non autorisé peut accumuler suffisamment d'informations pour briser le cryptage AES-128.

Par conséquent, EAP-PSK ne peut pas être considéré comme un exemple de preuve de mot de passe à connaissance zéro, bien que d'autres schémas d'authentification proposés basés sur EAP tels que EAP-SPEKE aient cette propriété.

Pour illustrer la partie problématique du protocole EAP-PSK, considérons le flux de messages tel que présenté dans la RFC 4764.

Le premier message est envoyé par le serveur au pair pour:

  *  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 Le deuxième message est envoyé par l'homologue au serveur pour:

  *  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 Le troisième message est envoyé par le serveur au pair pour:

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

Ici, AK fait partie de la clé secrète utilisée à ce stade et peut être révélée au serveur escroc capable de déchiffrer AES-128.