В настоящее время я играю с механизмом запроса/ответа WEP (аутентификация с общим ключом) и надеюсь, что кто-нибудь сможет мне помочь.
Мой вопрос:
Может ли кто-нибудь сказать мне состав 136-байтового ответа на вызов данных и почему он такого размера.
Почему это не Enc([challengetext (128)] + [icv(4)]) = 132 байта?
Спасибо.
Вы забыли 4 байта IV в начале.
Я не эксперт, и я использую личный опыт, чтобы подтвердить ответ на вопрос. Не стесняйтесь редактировать возможные неправильные термины.
Зашифрованный кадр, отправленный STA, содержит:
802.11 parameters (24 bytes)WEP parameters (очистить IV + индекс ключа) (4 bytes)management headers (зашифровано) (8 bytes)data (зашифровано) (128 bytes)ICV (зашифровано) (4 bytes)Всего 168 bytes, всего зашифрованных данных без ICV 136 bytes.
Зашифрованные данные, показанные Wireshark и Cie, на 8 байт длиннее, чем вызов в виде открытого текста, поскольку они также содержат заголовки управления (зашифрованные, но предсказуемые).
Кадр открытого текста, отправляемый точкой доступа, имеет длину 160 байт, а зашифрованный кадр ответа на запрос — 168 байт. Вопрос не в этом, но давайте проясним ситуацию.
В сообщениях AP с открытым текстом заголовки управления также являются открытым текстом:
2 bytes)2 bytes)2 bytes)1 byte)1 byte)'tag length' bytes)Заголовок управления имеет длину 8 байт.
В зашифрованном сообщении STA все, что выше уровня 802.11, считается «данными», поскольку это зашифрованная тарабарщина. Перед этими данными вы можете найти (часть уровня 802.11) параметры WEP: IV (3 bytes) и key index (1 bytes). Это чистый текст. У вас также есть ICV, самый последний 4 bytes кадра. Это 8 bytes, которые появляются во всех фреймах, зашифрованных WEP.
Раздел «данные» содержит зашифрованную задачу и зашифрованные заголовки управления (вот что отвечает на ваш вопрос).
Если у вас есть 8 дополнительных байтов во фрейме WEP, которые фактически компенсируют 8-байтовые заголовки управления, то почему ваши зашифрованные данные запроса на 8 байтов длиннее?
Это не из-за IV или ICV, как мы видели ранее, поскольку они не являются частью данных о вызове. Эти 8 байт на самом деле взяты из заголовков управления, которые зашифрованы в разделе «данные». Фрейм, содержащий зашифрованный вызов, также является кадром управления, но вы не можете видеть заголовки, поскольку они зашифрованы. Это ваши 8 таинственных байтов (см. упрощенные скелеты фреймов ниже)
Я закончу на том факте, что эти аутентификации с общим ключом позволяют вам выполнять офлайн-атаки с помощью словаря или грубой силы на захваты аутентификации WEP без какого-либо IV (кроме того, который используется для шифрования вызова, конечно). Тот факт, что первые 8 зашифрованных байтов являются заголовками управления, делает их предсказуемыми (всегда одно и то же). Таким образом, в реализации грубой силы вы можете просто RC4 первые 4 или 8 байтов кадра вместо целых 136 байтов, что приводит к более высокой производительности при атаках с огромным словарем/полным перебором.
--------------------------------------------------------------
(ieee 802.11 headers) -> 24 bytes
--------------------------------------------------------------
---------------- 8 bytes management headers ------------------
ieee 802.11 Wireless Management:
[0][1] == Authentication algo (int16) == 0x0100 (Shared Key)
[2][3] == Authentication SEQ (int16) == 0x0002
[4][5] == Status code (int16) == 0x0000 (Successful)
[6] == Tag Number (int8) == 0x10 (Challenge text)
[7] == Tag length (int8) == 0x80 (128 bytes long challenge)
--------------------------------------------------------------
---------------------- 128 bytes data ------------------------
[0:128]== Challenge text
--------------------------------------------------------------
24 + 8 + 128 = 160 bytes frame
--------------------------------------------------------------
(ieee 802.11 headers) -> 24 bytes
--------------------------------------------------------------
------------------ 4 bytes WEP parameters --------------------
[0][1][2] == IV (3 bytes, clear text)
[3] == key index (int8) (should be 0)
--------------------------------------------------------------
---------------- 8 bytes management headers ------------------
From here, everything is encrypted
[0][1] == Authentication algo (int16) == 0x0100 (Shared Key)
[2][3] == Authentication SEQ (int16) == 0x0003 (incremented since last frame)
[4][5] == Status code (int16) == 0x0000 (Successful)
[6] == Tag Number (int8) == 0x10 (Challenge text)
[7] == Tag length (int8) == 0x80 (128 bytes long challenge)
--------------------------------------------------------------
---------------------- 128 bytes data ------------------------
[0:128]== Encrypted data challenge
--------------------------------------------------------------
---------------------- 4 bytes ICV ---------------------------
[0:4] == WEP ICV
--------------------------------------------------------------
24 + 4 + 8 + 128 + 4 = 168 bytes frame
8 + 128 = 136 bytes "data" (as wireshark interprets it)
Единственное, что отличается от предыдущего в заголовках управления зашифрованным фреймом, это номер SEQ.
