Аутентификация клиента для подделки WPA AP без действительного PMK?

Question

Итак, я просматривал WPA и 4-сторонние механизмы рукопожатия, пытаясь провести мозговой штурм возможностей создания поддельной AP с WPA-шифрованием, вариант, который, кажется, отсутствует на авиабазе. Вот мои мысли: Я создаю поддельную AP с флагом шифрования WPA-PSK и устанавливаю ESSID в ESSID целевой точки. Отключив аутентификацию клиентов, подключенных к целевой точке доступа, нормальная реакция будет искать их AP в списке WiFi. Они попытаются подключиться к поддельной точке доступа, используя пароль, который я пытаюсь восстановить.

Согласно этой Википедии демонстрация 4-стороннего рукопожатия: https://en.wikipedia.org/wiki/IEEE_802.11i-2004#Protocol_operation ПТК никогда не делится на лету между AP и станцией (клиентом); вместо этого MIC сравниваются. В пакете 2/4 станция отправляет свой SNonce, подписанный с MIC. После получения этого пакета поддельная точка доступа пропустит построение PTK и просто отправит пакет 3/4 со случайно назначенным GTK и MIC (я не уверен, проверен ли этот MIC клиентом).

Итак, мои вопросы: Проверяет ли клиент MIC от 3-го пакета рукопожатия? Если это не так, значит ли это, что клиент успешно прошел аутентификацию и подключен к AP?

Дальнейшие мысли: В отсутствие AP-стороннего PTK я могу просто отправить необработанные незашифрованные пакеты данных клиенту с целью подмены DNS? В случае, если пакеты необработанных данных не принимаются клиентом, может ли использоваться уязвимость Hole196 (зарегистрированная здесь: http://www.airtightnetworks.com/WPA2-Hole196) для подмены DNS, учитывая, что GTK известен поддельной AP?

Надеюсь, вы увлечены моим вопросом; если вам потребуются дополнительные разъяснения, я буду рад ответить.

Answer 1

Хорошо, так что я прочитал в 802.11-2012 документации IEEE Std, и пришел к выводу, что моя концепция является недействительным и не представляется возможным по следующим причинам:
В разделе 11.6.2 из IEEE Std , в нижней части страницы 1249, появляется следующее утверждение:

Если GroupKey или SMK KDE входит в поле Key Data, но поле Key Data не зашифрован, EAPOL-Key кадры должны быть проигнорированы.

Это исключает возможность отправки незашифрованный GTK на просителя (клиента), зная, что отправка зашифрованной GTK на просителя не представляется возможным, а также в связи с тем, что поддельные AP не может генерировать фактический (клиентский) ПТК, необходимый для шифрования ключевых данных (включая GTK) в третьем сообщении EAPOL четырехстороннего рукопожатия.
Шифрование поля данных ключа в WPA2 CCMP обычно достигается с помощью алгоритма обертывания ключа NIST AES, зарегистрированного в IEFT RFC 3394.

Мое предположение о том, что GTK может быть отправлено запрашивающему, незашифрованному (до того, как я попал в этот раздел IEEE Std), также закончил полный сбой; это поясняется в разделе 11.6.6.4 стандарта IEEE Std 802.11-2012 на странице 1259:

На приеме сообщения 3, ..., проситель также:
...
б) Проверяется МИК сообщение 3. Если вычисленная MIC не соответствует MIC, что Authenticator включены в EAPOL-Key кадра, Supplicant молча отбрасывает сообщение 3.

Опять же, так как поддельные AP не может генерировать правильный ПТК, он может Не вычисляйте действительный MIC для сообщения 3, что приводит к отбрасыванию сообщения и сбою в работе.