Технология IPsec

Протокол АН

Протокол AH используется для аутентификации, но не для шифрования IP трафика, и служит для подтверждения, что мы связаны именно с тем, с кем предполагаем, и что полученные данные не искажены и не подменены при транспортировке.

.

Этот AH заголовок содержит пять важных полей.

Следующий заголовок

Идентифицирует тип протокола, используемого для следующего поля данных. Фактически это тип пакета, инкапсулированного в AH IPsec.

AH len

Определяет длину заголовка пакета, измеренную в 32-битовых словах, за вычетом двух слов (это диктуется RFC 1883 для IPv6).

Зарезервировано

Поле зарезервировано на будущее и должно содержать нули.

Индекс параметров безопасности (SPI)

32-битовый идентификатор, который помогает получателю выбрать, к какому из входных обменов относится этот пакет. Каждый обмен, защищенный AH, использует хэш-алгоритм (MD5, SHA-1 и т.д..), какие-то секретные и, возможно, некоторые иные данные. SPI может рассматриваться как индекс таблицы наборов таких параметров, чтобы облегчить выбор нужного набора.

Номер по порядку

Монотонно увеличивающийся идентификатор, который позволяет установить соответствие между посланным пакетом и откликом подтверждения его получения. Этот код включается в аутентификационные данные, что позволяет детектировать любые модификации, а также атаки воспроизведения.

Аутентификационные данные

Это контрольная сумма ICV (Integrity Check Value), вычисленная для всего пакета, включая большинство полей заголовка (см. рис. 17.3). Получатель повторно вычисляет тот же хэш. Если значения кодов не совпадут, пакет был поврежден в пути или не соответствует секретному ключу. Такие пакеты отбрасываются. ICV часто называется также МАС (Message Authentication Code). Для вычисления МАС используются следующие поля:

Транспортный режим

Транспортный режим применяется для защиты виртуальных соединений точка-точка. Эта защита осуществляется с использованием аутентификации, шифрования или обоих методов.

При транспортном режиме AH IP пакет модифицируется лишь слегка путем включения AH заголовка между IP заголовком и полем данных (TCP, UDP и т.д.) и перестановки кодов протокола.

Перестановка кодов протокола необходима для восстановления исходного вида IP пакетов конечным получателем: после выполнения проверки получателем корректности IPsec заголовка этот заголовок удаляется, а в поле код протокола IP заносится прежнее значение (TCP, UDP и т.д.).

Когда к адресату приходит пакет, успешно прошедший процедуру аутентификации, заголовок AH удаляется, а содержимое поля протокол (=AH) в IP заголовке заменяется запомненным значением поля следующий заголовок. Таким образом, восстанавливается первоначальный вид IP-дейтограммы и пакет может быть передан ожидающему процессу.

На рис 17.3 показано преобразование форматов заголовков в транспортном режиме IPsec. Слева на рисунке размешен формат исходной дейтограммы с инкапсулированным ТСР-сегментом. Закрашенные области защищены аутентификационными данными АН. Поля TOS, TTL, флаги, указатель (фрагмента) и контрольная сумма заголовка не защищаются, так как их содержимое может изменяться в процессе транспортировки, а промежуточные узлы не владеют необходимыми ключами для дешифрования и повторного шифрования.

Поля, не охватываемые защитой хэша, перед вычислением ICV заполняются нулями.

Туннельный режим

Режим туннеля реализует функциональность VPN, где IP пакет целиком инкапсулируются в другой пакет и в таком виде доставляются адресату.

Так же, как и в транспортном режиме, пакет защищается контрольной суммой ICV, чтобы аутентифицировать отправителя и предотвратить модификацию пакета при транспортировке. Но в отличие от транспортного режима, здесь инкапсулируется весь IP пакет, а это позволяет адресам отправителя и получателя отличаться от адресов, содержащихся в пакете, что дает возможность формировать туннель.

На рис 17.4 показано преобразование форматов заголовков в туннельном режиме IPsec. Слева на рисунке размешен формат исходной дейтограммы с инкапсулированным ТСР-сегментом. Закрашенные области защищены аутентификационными данными АН.

Когда пакет туннельного режима приходит адресату, он проходит ту же аутентификационную проверку, что и пакет AH-типа, после чего удаляются заголовки IP и AH и восстанавливается первоначальный формат пакета.

Большинство реализаций рассматривает оконечную точку туннеля в качестве сетевого интерфейса.

Реконструированный пакет может быть доставлен локальной машине или маршрутизован куда-либо еще (согласно IP-адресу места назначения в инкапсулированном пакете). Дальнейшая его транспортировка уже не обеспечивается средствами безопасности IPsec.

В то время как транспортный режим используется исключительно для обеспечения безопасной связи между двумя компьютерами, туннельный режим обычно применяется между шлюзами (маршрутизаторами, сетевыми экранами, или отдельными VPN устройствами) для построения VPN (Virtual Private Network).

Следует заметить, что в пакете IPsec нет специального поля "режим": которое бы позволяло разделить транспортный режим от туннельного, эту функцию выполняет поле следующий заголовок пакета AH.

Когда поле следующий заголовок соответствует IP, это означает, что пакет инкапсулирует всю IP-дейтограмму (туннельный режим), включая независимые адреса отправителя и получателя, которые позволяют реализовать маршрутизацию после туннеля.

Любое другое значение поля (TCP, UDP, ICMP и т.д.) означает транспортный режим (безопасная транспортировка по схеме точка-точка).

IP-дейтограмма верхнего уровня имеет ту же структуру вне зависимости от режима, и промежуточные маршрутизаторы обрабатывают трафик, не анализируя внутреннее содержание IPsec /AH.

Заметим, что ЭВМ, в отличие от сетевого шлюза, должна поддерживать как транспортный, так и туннельный режим, но при формировании соединения машина-машина формирование туннеля представляется избыточным.

Кроме того, для сетевого шлюза (маршрутизатора, сетевого экрана и т.д.) необходимо поддерживать туннельный режим, в то же время поддержка транспортного режима представляется полезной лишь для случая, когда шлюз сам является конечным адресатом (например, в случае реализации процедур удаленного управления сетью).

Алгоритмы аутентификации

AH содержит ICV (Integrity Check Value) в аутентификационной части заголовка, и эта контрольная сумма формируется обычно (но не всегда) с помощью стандартного криптографического хэш алгоритма, например, MD5 или SHA-1.

Здесь используется не традиционная контрольная сумма, которая не может предотвратить намеренное искажение содержимого, а алгоритм HMAC (Hashed Message Authentication Code), который при вычислении ICV применяет секретный ключ. Несмотря на то, что хакер может заново вычислить хэш, без секретного ключа он не сможет корректно сформировать ICV. Алгоритм HMAC описан в документе RFC 2104.

Заметим, что IPsec /AH не определяет, какой должна быть аутентификационная функция, вместо этого предоставляются рамки, в которых можно реализовать любую функцию, согласованную отправителем и получателем. Можно использовать для аутентификации цифровую подпись или криптографическую функцию, если оба участника их поддерживают.

AH и NAT

Именно потому, что AH обеспечивает хорошую защиту содержимого пакета, так как этот протокол покрывает все, что только нужно защитить, эта защита приводит к несовместимости с NAT (Network Address Translation).

Протокол NAT применяется для установления соответствия между частными IP-адресами (например, 19.125.1.X) и легальными IP. При этом IP-заголовок модифицируется устройством NAT путем замены IP-адресов отправителя и получателя.

Когда изменяются IP-адреса, нужно заново вычислить контрольную сумму заголовка. Это нужно сделать в любом случае. Так как устройство NAT обычно размещается в одном шаге между отправителем и получателем, это требует, кроме того, декрементации значения TTL (Time To Live).

Так как поля TTL и контрольная сумма заголовка всегда модифицируются на пролете, AH знает, что эти поля следует исключить из зоны защиты, но это не касается IP-адресов. Адреса включены в область вычисления ICV, и любая модификация вызовет сбой при проверке ICV получателем. Так как вычисление ICV требует знания секретного ключа, который неизвестен промежуточным узлам, маршрутизатор NAT не сможет заново вычислить ICV.

Аналогичная проблема возникает при использовании протокола PAT (Port Address Translation), который устанавливает соответствие нескольких частных IP адресов одному внешнему IP. В этом случае изменяются не только IP-адреса, но и коды портов в UDP и TCP пакетах (а иногда и в поле данных). Это требует много большей адаптивности со стороны устройства NAT, и более серьезных модификаций всей IP дейтограммы.

По этой причине протокол AH в туннельном или транспортном режиме полностью несовместим с NAT.

Заметим, что эта трудность не относится к ESP, так как аутентификация и шифрование в этом варианте не охватывает IP-заголовок, модифицируемый NAT. Несмотря на это, NAT создает определенные проблемы и для ESP.

Протокол NAT транслирует IP адреса "на пролете" — но он должен отслеживать то, с каким соединением происходит работа, чтобы корректно связывать отклики с источником пакетов. При использовании TCP или UDP это обычно делается с привлечением номеров порта, но IPsec не оставляет такой возможности.

На первый взгляд, можно предположить, что для решения проблемы можно использовать идентификатор SPI, но так как SPI отличаются для разных направлений обмена, для устройства NAT нет способа связать возвращаемый пакет с конкретным соединением.

ESP (Encapsulating Security Payload – поле данных безопасной инкапсуляции)

На рис 17.5 показан формат заголовка пакета ESP. Первое поле заголовка имеет длину 32 бита и содержит значение индекса параметров безопасности (SPI), которое определяет конкретный набор таких параметров, используемый для данного пакета. За ним следует 32-битовое поле номера по порядку.

Далее размещается поле зашифрованных данных, для выравнивания его длины (+ 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 "окружает" защищаемое поле данных. Поля ).

Возможно использование ESP без какого-либо шифрования (чтобы применить NULL алгоритм). Этот режим не обеспечивает конфиденциальности, и его имеет смысл применять в сочетании с аутентификацией ESP. Неэффективно использовать ESP без шифрования или аутентификации (если только это не делается для тестирования протокола).

Заполнение делается для того, чтобы сделать возможным применение блочных алгоритмов шифрования, длина поля ).

Помимо шифрования, ESP может опционно предоставлять возможность аутентификации, с привлечение алгоритма HMAC. В отличие от AH, однако, эта аутентификация производится только для ESP-заголовка и зашифрованного поля данных. При этом не перекрывается весь IP-пакет. Это несущественно ослабляет безопасность аутентификации, но дает некоторые важные преимущества.

Когда посторонний рассматривает IP-пакет, содержащий данные ESP, принципиально невозможно определить IP-адреса отправителя и получателя. Атакер конечно узнает, что это ESP данные (это видно из заголовка пакета), но тип поля данных и сами данные зашифрованы.

Глядя на сам пакет, невозможно даже определить, присутствуют или нет аутентификационные данные (это можно сделать, лишь используя индекс параметров безопасности).

ESP в транспортном режиме

Как и в случае AH, транспортный режим предполагает инкапсуляцию поля данных дейтограмм, и протокол ориентирован на обмен машина-машина. Исходный IP-заголовок оставлен на месте (за исключением замененного поля протокол ), и это означает, что адреса отправителя и получателя также остаются неизмененными.

Структура данных в пакете для протокола ESP в транспортном режиме показана на рис 17.6. Жирным контуром выделены аутентификацируемые данные, а закрашенная область отмечает шифруемую часть данных. Поле Next внизу рисунка характеризует тип протокола поля данных, закрашенного на рисунке (в приведенном примере это ТСР).

ESP в транспортном режиме

Посмотрим еще раз на ESP в туннельном режиме, когда инкапсулируется вся IP-дейтограмма внутрь зашифрованной оболочки.

Структура данных в пакете для протокола ESP в туннельном режиме показана на рис 17.7. Слева на рисунке размешен формат исходной дейтограммы с инкапсулированным ТСР-сегментом. Жирным контуром выделены аутентифицированные данные, а закрашенная область отмечает шифруемую часть данных. Поле Next внизу рисунка характеризует тип протокола данных (на рисунке закрашено, в приведенном примере это IP).

Реализация шифрованного соединения в туннельном режиме очень близка к традиционным VPN.

В отличие от AH, где наблюдатель может легко сказать, происходил обмен в туннельном или транспортном режиме, здесь эта информация недоступна, поскольку указание на то, что следующий заголовок является IP, находится в зашифрованном поле данных и поэтому не виден для участника, неспособного дешифровать пакет.

Построение VPN

При полном перекрытии аутентификационного заголовка и инкапсулированного поля данных можно построить настоящую VPN (Virtual Private Network). Конечной целью VPN является объединение двух безопасных сетей через небезопасные каналы (например, сети двух отделений компании через Internet). Схема построения VPN показана на рис 17.8. Предполагается, что обработка пакетов VPN на входе/выходе локальных сетей осуществляется в сетевых шлюзах (GW). Функции GW могут выполнять и сетевые экраны (Firewall).

Понятно, что безопасные VPN требуют применения как аутентификации, так и шифрования. Известно, что ESP является лишь средством обеспечения шифрования, но ESP и AH могут осуществлять аутентификацию.

На рис 17.9 показана структура VPN-пакета при использовании протокола ESP и аутентификации.

Поле Next в данном случае характеризует тип протокольного пакета, размещенного выше на рисунке (тип=IP, закрашенная область).

Очевидным решением является встраивание ESP в AH, что технически возможно, но на практике не используется, из-за ограничений AH в отношении протокола NAT. Применение комбинации AH и ESP не позволит использовать технику NAT.

Вместо этого, комбинация ESP и Auth используется в туннельном режиме при полной инкапсуляции трафика в процессе транспортировки через области сети, где нет гарантии безопасности.

Трафик, защищенный так, не предоставляет перехватчику информации о том, что два сетевых объекта соединены VPN. Эта информация могла бы оказаться атакеру полезной для понимания структуры отношений партнеров. В протоколе ESP даже тип транспортного протокола (TCP, UDP или ICMP) оказывается скрыт от постороннего.

Достаточно важно то, что даже конечный пользователь не знает ничего о VPN или других используемых мерах безопасности. VPN реализуется сетевым шлюзом, который выглядит как один из интерфейсов, маршрутизация же осуществляется обычным образом.

Вложение пакет-в-пакет может быть многослойным. ЭВМ A и ЭВМ B могут установить свое аутентифицированное соединение (с помощью протокола AH), и осуществлять маршрутизацию через VPN. Это приведет к тому, что внутренний пакет AH будет помещен внутрь пакета ESP+Auth.

Важно использовать аутентификацию даже в случае применения шифрования, так как такое соединение может стать объектом атаки, описанной в http://eprint.iacr.org/2005/416 (Paterson Yau).

Ассоциации безопасности и SPI

Кажется самоочевидным, что если два партнера или шлюза намереваются установить безопасное соединение, необходим некоторый объем общих секретных данных для реализации аутентификации и/или алгоритмов шифрования. Существует, конечно, проблема безопасной транспортировки этих секретных данных.

Когда IPsec -дейтограмма, AH или ESP попадает в интерфейс, как интерфейс узнает, какой набор параметров (ключ, алгоритм и политика) использовать? Любая машина может вести много диалогов, каждый со своим набором параметров безопасности, и нужен механизм управления этим процессом.

Параметры безопасности задаются SA ( Security Association ), которая определяет параметры и процедуры, специфические для конкретного соединения. Каждый партнер может иметь один или более SA. Когда дейтограмма приходит, для нахождения правильного SA в базе данных SADB (Security Associations Database – база данных ассоциаций безопасности) используются три значения:

Во многих отношениях эта тройка может быть уподоблена IP-сокету, который однозначно определяется IP-адресом удаленного партнера (IPv4 или IPv6), протоколом и номером порта. В перечень компонентов SA входят:

При создании новой SA в счетчик номера по порядку заносится нуль, далее он инкрементируется при посылке каждого пакета. Когда содержимое счетчика достигает значения 2³²-1, текущая SA аннулируется и должна быть согласована новая ассоциация безопасности и новый ключ.

Так как IP работает без установления соединения и доставка пакетов по порядку не гарантируется, протокол требует, чтобы получатель сформировал скользящее окно с шириной W, например, W=64 пакета. Правый край окна соответствует наибольшему номеру по порядку N для благополучно принятых пакетов. Любой пакет с номером в диапазоне от N-W+1 до N считается принятым корректно. Если полученный пакет оказался по левую границу окна или его аутентификация потерпела неудачу, то такой пакет отбрасывается. Ниже приведен пример из [17.1], где длина W=7 (реально это число может достигать 232). Первые две строки показывают состояние окна с началом в позиции 1 и концом в позиции 7, пакет с номером 9 получен, но его подлинность не подтверждена. Буквами П обозначены полученные пакеты с подтвержденной подлинностью, буквами Н – неполученные пакеты; а буквой О — полученный пакет, подлинность которого не подтверждена. Серым цветом отмечено окно W.

Когда подлинность полученного пакета с номером 9 оказалась подтвержденной, правая граница окна смещается на эту позицию и занимает положение, показанное на вторых строках данного примера. В этом состоянии, если придет пакет с номером 1 или 2, они будут отвергнуты. Если же придут пакеты с номерами 5 или 8 они будут подвергнуты обработке, так как находятся в пределах окна W.

Ассоциации безопасности сопрягаются с однонаправленными соединениями, так что для двунаправленной связи требуется как минимум две такие ассоциации. Кроме того, каждый протокол (ESP/AH) имеет свою собственную SA, для каждого из направлений обмена, таким образом, полномасштабная VPN AH+ESP требует наличия четырех ассоциаций безопасности. Все эти данные хранятся в базе данных SADB.

В базе данных SADB содержится:

Некоторые реализации поддерживают SPD (Security Policy Database) со средствами работы из командной строки, другие с GUI, в то время как прочие предоставляют WEB-интерфейс для работы через сеть. Каждая запись в SPD определяется набором значений полей IP и протокола верхнего уровня, называемых селекторами. Эти селекторы используются для фильтрации исходящего трафика, чтобы поставить его в соответствие с определенной SA. Обработка исходящих IP-пакетов производится в следующей последовательности.

SPD-запись определяется следующими селекторами.

Управление ключами

Для управления ключами используется несколько протоколов. IPsec был бы бесполезным без шифрования и аутентификации, которые, в свою очередь, невозможны без секретных ключей, известных партнерам обмена и не известных больше никому.

Наиболее простым способом задания этих секретных ключей является ручная конфигурация: один партнер генерирует набор ключей и передает ключи другим партерам.

Но такая схема плохо масштабируется, кроме того, кто-то из партнеров может пренебречь мерами безопасности и в результате вся сеть будет скомпрометирована. В больших системах с большим числом узлов такая схема обычно не приемлема.

Система IKE (Internet Key Exchange) позволяет двум партнерам динамически аутентифицировать друг друга, согласовать использование ассоциации безопасности (Security Association), включая секретные ключи, и генерировать сами ключи. Система IKE использует ISAKMP (Internet Security Association Key Management Protocol – протокол управления ключами ассоциации безопасности Интернет, разработан Национальным агентством безопасности США — NSA). Протокол ISAKMP сам по себе не регламентирует какой-либо конкретный алгоритм обмена ключами, он содержит в себе описание ряда сообщений, которые позволяют согласовать использование алгоритмов обмена ключами. Согласование осуществляется в два этапа.

Механизм обмена ключами в IKE берется из протокола Oakley (RFC-2412). Основой протокола обмен ключами Oakley является алгоритм Диффи-Хелмана (см. http://book.itep.ru/6/difi_646.htm), дополненный некоторыми усовершенствованиями. В частности, в каноническом алгоритме Диффи-Хелмана отсутствует аутентификация партнеров, что допускает возможность атаки с подменом ключей. В IPsec версии алгоритма аутентификация партнеров является обязательной процедурой.

Заметим, что IPsec осуществляет пересылку ключей через порт 500/udp . В IPsec при обмене ключами предусмотрено использование сертификатов. Для получения сертификата посылается запрос в сертификационный центр СА (Certificate Authority). Сертификация включает в себя следующие операции.

Клиенты могут пользоваться одним и тем же СА или быть клиентами разных СА. На практике обычно реализуется иерархическая структура СА.

В Интернет имеется огромное количество материалов по проблематике IPsec, но начинать всегда лучше с документов RFC (Requests for Comment), которые со временем обретают статус стандартов.

В декабре 2005, весь набор документов RFC по IPsec был обновлен IETF, а серия RFC 43xx по большей части заменила серию RFC 24xx.