3.3.3.4. Обзор протокола ipSec
Протокол IPSec был спроектирован специально созданной рабочей группой при IETF (Группа по проблемам проектирования Internet). Перед ней была поставлена задача создать единый стандарт, который обеспечивал бы высококачественное, гибкое и способное к совместной работе решение для сетей IPv4 и IPv6. Разработка была начата по инициативе организации Automotive Network Exchange (Сетевой обмен автомобилестроительной информацией - ANX), которой требовалась безопасная инфраструктура связи между производителями, поставщиками и клиентами.
Рабочая группа по протоколу безопасности IP (IP Security Protocol Working Group) разрабатывает механизмы защиты IP-трафика путем определения структуры защищенных IP-пакетов и реализации параметров безопасности (security associations) для коммуникаций в сетях VPN. Хотя в части управления ключами протокол еще не завершен, но протоколы для аутентификации данных, обеспечения конфиденциальности и целостности уже определены.
Протокол IPSec состоит из трех основных частей, которые определяют два режима его работы (АН и ESP):
- АН (Authentication Header - заголовок аутентификации) обеспечивает аутентификацию источника данных, целостность и защиту от воспроизведения;
- ESP (Encapsulating Security Payload - безопасно инкапсулированная полезная нагрузка) обеспечивает аутентификацию источника данных, целостность, защиту от воспроизведения, конфиденциальность данных и до некоторой степени скрытность управления потоком;
- IKE (Internet Key Exchange - схема обмена ключами через Internet) предоставляет средства согласования криптографического алгоритма и отвечает за распределение ключей, используемых в АН и ESP.
Оба режима - АН и ESP - полагаются на механизм согласования сторонами параметров безопасного соединения (security association - SA) по алгоритму IKE. В SA хранятся параметры, о которых договорились оба участника обмена по сети VPN. К ним относятся криптографические ключи и время их жизни, используемые криптографические алгоритмы и режим работы протокола IPSec.
Для каждого режима работы нужно два SA: для входящего и исходящего трафика. Эти два набора параметров, описывающих данные, отправляемые и получаемые хостом, называются парой SA (SA bundle). Если одновременно используются оба режима работы (АН и ESP), то нужно согласовать четыре SA. В каждом SA явно указывается протокол АН или ESP, IP-адрес получателя для исходящего соединения или IP-адрес отправителя для входящего соединения и 32-битовое целое число (SPI), служащее уникальным идентификатором.
Еще одна важная характеристика SA - время жизни. Этот параметр определяет интервал времени, по истечении которого следует провести повторное согласование или считать SA недействительным. Время жизни задается либо как число обработанных байтов, либо как временной интервал; по достижении любого из этих порогов начинается повторное согласование SA. Существует два значения порога времени жизни SA: жесткий и мягкий. Когда достигнут мягкий порог, SA согласуется заново, по достижении же жесткого порога SA удаляется из памяти хоста. Каждый хост-участник хранит SA в базе данных параметров безопасности (Security Associations Database - SAD).
Для правильной работы IPSec нужна база данных политик безопасности (Security Policy Database - SPD), в которой хранятся сведения о политиках, применяемых к трафику. SPD содержит набор правил, которые, в свою очередь, состоят из селекторов, несущих информацию о типах выполняемых действий. Когда приходит пакет, по базе данных SPD определяется, что с ним делать: отбросить, пропустить дальше или передать для обработки протоколу IPSec. В отличие от SPD, база данных SAD лишь хранит необходимые параметры соединения. Для принятия решения о том, что делать с пакетом, из заголовка извлекаются три поля, которые сопоставляются с информацией, хранящейся в SAD (протокол IPSec, IP-адрес и SPI). Если соответствие найдено, то далее параметры сравниваются с полями АН или ESP. Если соответствие не найдено, пакет отбрасывается.
Протокол АН. АН - это один из протоколов, определенных в IPSec, он позволяет проверить аутентичность данных и заголовка IP-пакета в соответствии с рисунком 3.16. АН не предоставляет механизма для шифрования данных, но вычисляет свертку, которая дает возможность узнать, не был ли пакет изменен по пути следования. Такое применение не нашло широкого распространения, в отличие от протокола ESP.
Рис. 3.16. Формат пакета протокола AH
Протокол АН также отвечает за защиту от атак повтора сеанса, для этого в пакет включается порядковый номер и на каждом узле IPSec реализуется скользящее окно. Как только поступает IP-пакет, скользящее окно продвигается вперед, и все последующие пакеты с номерами вне этого окна отбрасываются. То же относится к пакетам с повторяющимися порядковыми номерами[15].
Аутентификацию пакета обеспечивает механизм НМАС. Если любая часть IP-заголовка или данных была изменена, то дайджест сообщения, вычисляемый хостом-получателем, будет отличаться от исходной свертки. Таким образом, гарантируется целостность передаваемых данных.
Для вычисления кода НМАС протокол IPSec допускает использование различных односторонних функций хэширования, в том числе MD5, SHA-1/2 и RIPEMD-160.
Протокол АН может работать в туннельном и транспортном режимах, а в RFC 2402 ему присвоен тип протокола 51.
Протокол ESP. Этот протокол обеспечивает инкапсуляцию незащищенного IP-пакета, его шифрование и аутентификацию в соответствии с рис. 3.17.
Традиционно в IPSec использовался шифр DES или 3DES. Шифр DES считается слабым и может быть вскрыт при необходимости за несколько дней или даже часов, поэтому пользоваться им не рекомендуется. Шифр 3DES гораздо более стоек, но требует большого объема вычислений и медленно работает на маломощных устройствах, таких как точки доступа, старые ПК и карманные компьютеры. Защита целостности данных обычно обеспечивается вычислением свертки данных пакета по алгоритму MD5 или SHA-1. Защита от атак воспроизведением реализована так же, как в протоколе АН. Протоколу ESP в RFC 2402 присвоен тип 50.
Существуют и другие реализации IPSec, к примеру Rijndael и другие финалисты конкурса на звание AES. Поддерживаются также более стойкие криптографические функции хеширования, например SHA-2 и RIPEMD.
Рис. 3.17. Шифрование и аутентификации с помощью протокола ESP
Сжатие IP. Добавление новых заголовков к IP-пакету после инкапсуляции ведет к увеличению размера пакета, то есть к накладным расходам на организацию туннеля. В случае протокола ESP пакет может вырасти на целых 300 байт. Если же совместно с ESP применяется и протокол АН, то цифра может и еще увеличиться. Это негативно сказывается на производительности, так как реальная пропускная способность сети падает. По сравнению с современными локальными сетями, у беспроводных сетей меньше полоса пропускания и пропускная способность, так что лишние накладные расходы нежелательны[15,43].
В протоколе IPSec предпринята попытка решить эту проблему за счет встроенного протокола сжатия IP-пакетов (IPComp), в котором обычно применяются алгоритмы DEFLATE или LZS.DEFLATE. Сжатие выполняется до модификации в соответствии с IPSec и до фрагментации. Часто бывает бесполезно сжимать случайные или уже сжатые данные (например, файлы типа mpЗ или .гаг), более того, иногда применение избыточного сжатия приводит даже к увеличению размера IP-пакета. Кроме того, если IPSec-туннель строится поверх протоколов РРР или SLIP, то сжатие уже могло быть произведено на более низком уровне, так что если в этом случае включить протокол IPComp, то пострадает производительность сети в целом, поскольку данные будут подвергнуты сжатию дважды.
Применение протокола IPComp должно быть согласовано обеими сторонами с помощью механизма IKE. Следует отметить, что IPComp достаточно гибок, он позволяет выборочно применять сжатие только к конкретному протоколу транспортного уровня или лишь на одном конце соединения.
Протокол обмена и управления ключами в IPSec. Протокол обмена и управления ключами в IPSec (IPSec Key Exchange and Management Protocol - ISAKMP) входит в набор протоколов IPSec и определяет процедуры согласования, создания, модификации и удаления SA, а также форматы соответствующих пакетов. Он спроектирован так, чтобы не зависеть ни от какого конкретного метода обмена ключами или генерации ключей, криптографического алгоритма или механизма аутентификации. ISAKMP описывает лишь общий каркас в довольно абстрактных терминах. Мы рассмотрим более подробно механизм IKE, основанный на каркасе ISAKMP.
Протокол IKE. Internet Key Exchange (IKE) - это протокол общего назначения, предназначенный для обмена информацией, относящейся к безопасности. Он предоставляет вспомогательный сервис для аутентификации узлов в протоколе IPSec, согласования параметров безопасности (SA) и ключей алгоритмов шифрования. Описание областей, в которых может применяться протокол IKE, см. в RFC 2407.
IKE имеет два разных режима, которые работают на одном или двух этапах каркаса ISAKMP. Этап 1 служит для установления безопасного канала, который позже используется для защиты всех переговоров, происходящих на этапе 2. По существу, SA в каркасе ISAKMP определяется после завершения всех переговоров между сторонами.
На этапе 1 выполняются следующие действия:
- аутентификация и защита IPSec-узлов;
- согласование политики для защиты обмена информацией по протоколу IKE;
- аутентифицированный обмен данными по протоколу Диффи-Хеллмана с целью выработки разделяемого секретного ключа;
- организация туннеля для последующих переговоров на этапе 2 ЖЕ.
На этапе 2 согласуются SA, которые необходимы для организации IPSec-туннеля, защищающего IP-трафик. Тот единственный SA, который был выработан на этапе 1, можно использовать для согласования SA на этапе 2.
На этапе 2 выполняются следующие действия:
- согласование параметров SA для протокола IPSec;
- выработка SA для протокола IPSec;
- периодическое проведение повторного согласования SA.
Чтобы стороны могли безопасно обменивать информацией, необходимо вначале успешно провести взаимную аутентификацию. Типичная реализация IPSec использует для этой цели следующие методы:
- предварительно разделенный ключ (Preshared Key - PSK). Этот метод аутентификации основан на доказательстве того факта, что обе стороны владеют общим секретом. Скомпрометировать это решение может небезопасная процедура распределения PSK;
- алгоритм с открытым ключом. Этот метод аутентификации основан на генерировании пары ключей (открытого и закрытого). Открытые ключи можно без опаски передавать по небезопасным каналам связи, но возникает вопрос об истинном владельце ключа;
- цифровые сертификаты. Любая схема распределения открытых ключей требует на каком-то этапе доверия. В таких сетях, как Internet где контроль сомнителен, а инфраструктуре нельзя доверять, распределять ключи нелегко. То же относится и к беспроводным сетям, которые к тому же уязвимы к атакам «человек посередине». В этом случае на сцену входит третья сторона - признанный удостоверяющий центр (СА), который выпускает сертификаты, содержащие идентификатор владельца, имя или IP-адрес машины, порядковый номер, срок действия и открытый ключ. Стандартный формат цифрового сертификата называется Х.509.
Режимы работы на этапе 1.
Есть три способа провести согласование SA на этапе 1:
- основной режим. Он спроектирован так, чтобы отделить информацию об обмене ключами от информации, касающейся идентификации и аутентификации, и защитить идентификационную информацию ранее сгенерированным по протоколу Диффи-Хеллмана разделяемым секретом. В этом режиме происходит обмен шестью UDP-датаграммами;
- агрессивный режим. В этом режиме разрешено передавать информацию, касающуюся обмена ключами, идентификации и аутентификации, вместе. Он часто применяется, когда защищать идентификационную информацию необязательно. Происходит обмен тремя UDP - датаграммами. После получения первого сообщения с предложением на генерирование ответа затрачивается много вычислительных ресурсов. Если подряд посылается несколько поддельных сообщений с предложениями, то ресурсы могут быть исчерпаны и произойдет отказ от обслуживания;
- базовый режим. Происходит обмен четырьмя UDP - датаграммами. В этом режиме сложные вычисления, выполняемые в агрессивном режиме, откладываются до того, как инициирующая сторона не подтвердит свое существование. Предполагается, что в этом режиме сохранены все достоинства агрессивного режима, но если стороны не пользуются шифрованием с открытым ключом, то информация об идентификации не защищена.
Режим работы на этапе 2.
На этапе 2 протокола IKE есть только один режим согласования - быстрый (Quick Mode). Он начинается после того, как IKE успешно организовал безопасный туннель в режиме 1. Поэтому все данные, которыми обмениваются стороны, зашифрованы. Соединение может быть запрошено любой стороной; один или более SA, необходимые для протокола IPSec, передаются в трех сообщениях, которыми обмениваются хосты.
Еще одной особенностью протокола IPSec является оппортунистическое шифрование. Идея оппортунистического шифрования состоит в том, чтобы дать сторонам возможность безопасно обмениваться данными, заранее ничего не зная, друг о друге. Прежде чем посылать пакет, отправляющая сторона проверяет, можно ли установить безопасный канал с принимающей [3] .
Рис. 3.18. Пример архитектуры защищенной сети передачи данных стандарта IEEE 802.11 построенной на базе VPN