IPSec. ESP vs AH. Практика.
2021.07.12. Kurapov Alexey.
IPSec. ESP vs AH
Рассмотрим топологию из статьи IPSec Настройка. Практика.
1. Применение ESP:
Запустим ping с R1 до R2:
Данные из Wireshark:
Первый ICMP Request:
Второй ICMP
Request:
Значения SPI совпадают.
ICMP Reply:
Sequence
- Монотонно увеличивающийся идентификатор, который позволяет установить
соответствие между посланным пакетом и откликом подтверждения его получения.
Этот код включается в аутентификационные данные, что позволяет детектировать
любые модификации, а также атаки воспроизведения.
2. Применение AH:
Запустим ping с R1 до R2:
Данные из Wireshark:
Как мы видим AH не обеспечивает шифрование вложенных данных.
Протокол AH используется для
аутентификации, но не для шифрования IP трафика, и служит для подтверждения
того, что мы связаны именно с тем, с кем предполагаем, что полученные данные не
искажены и не подменены при транспортировке.
Аутентификация выполняется путем, вычисления зашифрованного аутентификационного хэш-кода
сообщения. Хэширование охватывает практически все поля IP пакета (исключая
только те, которые могут модифицироваться при транспортировке, например, TTL
или контрольная сумма заголовка). Этот код записывается в AH заголовке и
пересылается получателю. Формат AH заголовка:
Формат заголовка протокола AH
AH заголовок содержит пять полей.
Следующий заголовок
Идентифицирует тип протокола, используемого для следующего поля данных.
Фактически это тип пакета, инкапсулированного в AH IPsec.
AH len
Определяет длину заголовка пакета, измеренную в 32-битовых словах, за
вычетом двух слов.
Зарезервировано
Поле зарезервировано на будущее и должно содержать нули.
Индекс параметров безопасности (SPI)
32-битовый идентификатор, который помогает получателю выбрать, к какому из
входных обменов относится этот пакет. Каждый обмен, защищенный AH, использует
хэш-алгоритм (MD5, SHA-1 и т.д..), какие-то секретные и возможно некоторые иные
данные. SPI может рассматриваться как индекс таблицы наборов таких параметров,
чтобы облегчить выбор нужного набора.
Номер по порядку
Монотонно увеличивающийся идентификатор, который позволяет установить
соответствие между посланным пакетом и откликом подтверждения его получения.
Этот код включается в аутентификационные данные, что позволяет детектировать
любые модификации, а также атаки воспроизведения.
Аутентификационные данные
Это контрольная сумма ICV (Integrity Check Value),
вычисленная для всего пакета, включая большинство полей заголовка (см. рис. 3).
Получатель повторно вычисляет тот же хэш. Если значения кодов не совпадут,
пакет был поврежден в пути или не соответствует секретному ключу. Такие пакеты
отбрасываются. ICV часто называется также МАС (Message
Authentication Code). Для вычисления МАС используются следующие поля:
·
Поля IP-заголовка, которые не меняются при транспортировке.
·
Заголовок АН, кроме поля данных аутентификации
·
Поле данных протокола верхнего уровня, которые остаются неизменными при
транспортировке.
На рисунке ниже показан формат заголовка пакета ESP. Первое поле заголовка
имеет длину 32 бита и содержит значение индекса параметров безопасности (SPI),
которое определяет конкретный набор таких параметров, используемый для данного
пакета. За ним следует 32-битовое поле номера по порядку.
Рис. 5. Формат ESP-пакета
Далее размещается поле зашифрованных данных, для выравнивания его длины (+
2 октета Pad len и Next hdr) до кратного размеру
блока шифрования может использоваться поле заполнитель, которое, как и поле
данных, может иметь переменную длину. После поля заполнителя размещается
хвостовик, содержащий два однооктетных поля: длины заполнителя (Pad len)
и кода следующего заголовка (Next hdr). Поле Next hdr характеризует
тип поля данных, расположенного выше на рисунке. Протокол ESP требует, чтобы
поля Pad len и Next hdr были выровнены по
правому полю 32-битового слова. Для решения этой задачи также может
использоваться поле заполнитель.
Добавление шифрования делает ESP несколько более сложным, из-за того, что
служебные поля ESP окружают поле данных, а не предшествует ему, как это сделано
в протоколе AH: ESP включает в себя поля заголовка и хвостовика.
Документы RFC IPsec не регламентируют конкретный алгоритм шифрования, но
допускают использование DES, triple-DES, AES и Blowfish для шифрования поля
данных. Алгоритм, используемый для конкретного соединения,
специфицируется ассоциацией безопасности SA, SA включает в
себя не только алгоритм, но и используемый ключ.
В отличие от протокола AH, который вводит небольшой заголовок перед полем
данных, ESP “окружает” защищаемое поле данных. Поля индекс параметров
безопасности (Security Parameters Index) и номер по порядку служат для
тех же целей, что и в случае AH, но в ESP имеются также поля заполнителя,
следующего заголовка, и опционно аутентификационных данных в
конце, в хвостовике ESP.
Заполнение делается для того, чтобы сделать возможным применение блочных
алгоритмов шифрования, длина поля заполнителя определяется значением поля pad
len. Поле next hdr определяет тип протокола поля
данные (IP, TCP, UDP и т.д.)
Помимо шифрования, ESP может опционно предоставлять возможность
аутентификации, с привлечение алгоритма HMAC. В отличие от AH, однако, эта
аутентификация производится только для ESP заголовка и зашифрованного поля
данных. При этом не перекрывается весь IP пакет. Это не существенно ослабляет
безопасность аутентификации, но дает некоторые важные преимущества.
Когда посторонний рассматривает IP пакет, содержащий данные ESP,
принципиально невозможно определить IP адреса отправителя и получателя. Конечно
можно узнать, что это ESP данные (это видно из заголовка пакета), но тип поля
данных и сами данные зашифрованы.
Глядя на сам пакет, невозможно даже определить, присутствуют или нет
аутентификационные данные (это можно сделать лишь, используя индекс параметров
безопасности).
Комментарии
Отправить комментарий