Протоколы ipsec и распределение ключей

Протокол IPSec или, если точнее, набор протоколов, разработан организацией IETF как базовый протокол обеспечения безопасности на уровне IP-соединения. Он является дополнением к использующемуся сейчас протоколу IP ver.4 и составной частью IP ver.6. Возможности, предоставляемые протоколами IPSec:

- контроль доступа;

- контроль целостности данных;

- аутентификация данных;

- защита от повторений;

- обеспечение конфиденциальности.

Основная задача IPSec – создание между двумя компьютерами, связанными через общедоступную (небезопасную) IP-сеть, безопасного туннеля (Рисунок 3.2), по которому передаются конфиденциальные или чувствительные к несанкционированному изменению данные. Подобный туннель создается с использованием криптографических методов защиты информации. Протокол работает на сетевом уровне модели OSI и, соответственно, он «прозрачен» для приложений. Иными словами, на работу приложений (таких как web-сервер, браузер, СУБД и т. д.) не влияет, используется ли защита передаваемых данных с помощью IPSec или нет. Архитектура IPSec является открытой, что позволяет использо-вать для защиты передаваемых данных новые криптографические ал-горитмы, например, соответствующие национальным стандартам. Для этого необходимо, чтобы взаимодействующие стороны поддерживали эти алгоритмы, и они были бы стандартным образом зарегистрированы в описании параметров соединения.

Процесс защищенной передачи данных регулируется правилами безопасности, принятыми в системе. Параметры создаваемого туннеля описывает информационная структура, называемая контекст защиты или ассоциация безопасности (от англ. «Security Association», сокр. SA). Как уже отмечалось выше, IPSec является набором протоколов, и состав контекста защиты может различаться. В зависимости от конкретного протокола в него входит:

- IP-адрес получателя;

- указание на протоколы безопасности, используемые при передаче данных;

- ключи, необходимые для шифрования и формирования имитовставки (если это требуется);

- указание на метод форматирования, определяющий, каким образом создаются заголовки;

- индекс параметров защиты (от англ. «Security Parameter Index», сокр. SPI) – идентификатор, позволяющий найти нужный SA.

Обычно, контекст защиты является однонаправленным, а для передачи данных по туннелю в обе стороны задействуются два SA. Каждый хост имеет свою базу контекстов защиты, из которой выбирается нужный элемент либо на основании значения SPI, либо по IP-адресу получателя.

Два протокола, входящие в состав IPSec это:

1) протокол аутентифицирующего заголовка – AH (от англ. «Authentication Header»), обеспечивающий проверку целостности и аутентификацию передаваемых данных; последняя версия протокола опи-сана в документе RFC 4302 (предыдущие – RFC 1826, 2402);

2) протокол инкапсулирующей защиты данных – ESP (от англ. «Encapsulating Security Payload»), обеспечивающий конфиденциальность и, опционально, проверку целостности и аутентификацию; описан в RFC 4303 (предыдущие версии – RFC 1827, 2406).

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

Транспортный режим ориентирован на соединение хост-хост. При использовании ESP в транспортном режиме защищаются только данные IP-пакета, заголовок не затрагивается. При использовании AH защита распространяется на данные и часть полей заголовка. Более подробно режимы работы описаны ниже.

Протокол AH

IP ver.4 аутентифицирующий заголовок располагается после IP-заголовка. Представим исходный IP-пакет как совокупность IP-заголовка, заголовка протокола следующего уровня (как правило, это TCP или UDP, на Рисунок 4.3 он обозначен как ULP – от англ. «Upper-Level Protocol») и данных.

Рисунок 3.3- а) исходный IP-пакет, б) IP-пакет при использовании AH в транспортном режиме, в) IP-пакет при использовании AH в туннельном режиме

На рисунке 3.3. представлен исходный пакет и варианты его изменения при использовании протокола AH в разных режимах. В транспортном режиме заголовок исходного IP-пакета остается на своем месте, но в нем модифицируются некоторые поля. Например, меняется поле Next Header, указывающее на то, заголовок какого протокола следует за IP-заголовком. В туннельном режиме создается новый IP-заголовок, после которого идет заголовок AH, а за ним – полностью исходный IP-пакет.

Аутентификация производится путем создания имитовставки (MAC) для чего используется хэш-функция и секретный ключ. Во всех реализациях AH обязательно должно поддерживаться использование алгоритмов HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96, представляющих собой хэш-функции с ключом, основанные на хэш-функциях MD5 и SHA-1, соответственно. Но могут использоваться и другие, «факультативные» алгоритмы хэширования. Полученное значение, называемое в описании протокола ICV (от англ. «Integrity Check Value» – значение контроля целостности) помещается в поле Authentication Data (Рисунок 3.4). Это поле перемен ной длины, так как разные алгоритмы хеширования формируют разные по длине дайджесты.

При использовании AH в транспортном режиме, ICV рассчитывается для ULP, данных и неизменяемых полей IP-заголовка. Изменяемые поля, такие как поле TTL, указывающее на время жизни паке-та и изменяемое при прохождении маршрутизаторов, при расчете значения хэш-функции принимаются равными 0. В туннельном режиме аутентифицируется весь исходный IP-пакет и неизменяемые поля нового заголовка. Рассмотрим формат заголовка AH (Рисунок 3.3).

Первые 8 бит заголовка (поле Next Header) содержат номер, соответствующий протоколу следующего уровня. Номер для каждого протокола назначает организация IANA (Internet Assigned Numbers Authority). Например, номер TCP – 6, ESP – 50, AH – 51 и т. д.

Поле Payload Len указывает длину заголовка AH в 32-битных словах. Далее 16 бит зарезервировано.

Рисунок 3.4. Структура заголовка протокола AH

Поле SPI содержит значение индекса параметров защиты, по которому получатель сможет найти нужный контекст защиты (SA).

Поле Sequence Number было введено в RFC 2402. Значение счетчика, содержащееся в этом поле, может использоваться для защиты от атак путем повторных посылок перехваченных пакетов. Если функция защиты от повторов активирована (а это указывается в SA), отправитель последовательно наращивает значение поля для каждого пакета, передаваемого в рамках данной ассоциации (соединения, использующего единый SA).

Поле Authentication Data, как уже указывалось ранее, хранит значение ICV.

Протокол ESP

Если AH обеспечивает защиту от угроз целостности передаваемых данных, то ESP также может обеспечивать и конфиденциальность.

Так же как и AH, ESP может работать в транспортном и туннельном режимах. На Рисунок 3.5 изображены варианты его использования (штриховкой выделены фрагменты пакета, которые защищаются с помощью шифрования). Для ESP определен следующий перечень обязательных алгоритмов, которые должны поддерживаться во всех реализациях:

- для формирования имитовставки HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96;

- для шифрования – DES (в режиме CBC; используется по умолчанию) и NULL (отсутствие шифрования).

Кроме того, зарегистрированы и могут быть реализованы еще ряд алгоритмов шифрования – Triple DES, CAST-128, RC5, IDEA, Blowfish, ARCFour (общедоступная версия RC4) [13].

	Рисунок 3.5	- а) исходный IP-пакет,
			б) ESP в транспортном режиме,
			в) ESP в туннельном режиме

Рассмотрим формат заголовка ESP (Рисунок 4.6). Он начинается с двух 32-разрядных значений – SPI и SN. Роль их такая же, как в протоколе AH – SPI идентифицирует контекст защиты, использующийся для создания данного туннеля; SN – позволяет защититься от повторов пакетов. SN и SPI не шифруются. Следующим идет поле, содержащее зашифрованные данные. После них - поле заполнителя, который нужен для того, чтобы выровнять длину шифруемых полей до значения кратного размеру блока алгоритма шифрования.

После заполнителя идут поля, содержащие значение длины заполнителя и указание на протокол более высокого уровня

Рисунок 3.6. Структура заголовка ESP

Четыре перечисленных поля (данные, заполнитель, длина, следующий протокол) защищаются шифрованием.

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

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

Рассмотрим ряд дополнительных вопросов, связанных с использованием IPSec. Начнем с того, откуда берется информация о пара-метрах соединения – контекстах защиты или SA. Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности вручную, или формироваться с использованием специальных протоколов – SKIP, ISAKMP (Internet Security Association and Key Management Protocol) и IKE (Internet Key Exchange).

Протокол SKIP

Протокол SKIP (Simple Key management for Internet Protocol)

был разработан корпорацией SUN Microsystems в 1994 году. Он создавался как IP-совместимый протокол, обеспечивающий управление ключами и криптозащиту передаваемых данных на сетевом уровне модели OSI [13]. По нумерации IANA этому протоколу присвоен номер 57.

Первоначально SKIP выглядел следующим образом. Устанавливающие защищенное взаимодействие абоненты должны иметь аутентифицированные открытые ключи. По алгоритму ДиффиХеллмана они вычисляют общий секретный ключ K_ij. Он используется для защиты ключевой информации.

Отправитель генерирует временный ключ K_p, используемый для шифрования данных одного пакета или небольшой их группы. На нем зашифровывается исходный IP-пакет и инкапсулируется в SKIP-пакет (Рисунок 3.7). Шифрование данных на временном ключе, а не на общем секретном ключе K_ij, повышает надежность, так как в этом случае нарушителю труднее набрать нужный для реализации атаки на K_ij объем шифрованных данных. Далее в заголовке идут байтовые идентификаторы алгоритмов: шифрования ключа K_p – K_ij Alg, шифрования данных в пакете – Crypt Alg,аутентификации данных– MAC Alg,сжатия(если используется) – Comp Alg. После идентификаторов в SKIP-заголовок помещается ключ K_p, зашифрованный на ключе K_ijn (размер этого поля за-висит от используемых алгоритмов шифрования ключа и данных). Далее идут идентификаторы отправителя и получателя в выбранном пространстве имен – Source MKID и Dest MKID. Наличие нескольких идентификаторов позволяет более гибко настраивать использование протоколов безопасности. Например, если на одном компьютере работают различные приложения, можно описать политику, указывающую какие алгоритмы и ключи использовать для защиты данных каждого из них.

Протоколы ISAKMP и IKE

Протокол ISAKMP (Internet Security Association Key Management Protocol – протокол управления ключами и контекстами безопасности в Internet) был разработан IETF для решения задач согласования параметров и управления ключами при формировании защищенного канала. ISAKMP описывает общую схему взаимодействия, но не содержит конкретных криптоалгоритмов распределения ключей. Поэтому он используется совместно с протоколом OAKLEY, основанном на алгоритме Диффи-Хеллмана [13]. Протокол IKE (англ. «Internet Key Exchange» – обмен ключами в Internet) определяет совместное использование протоколов ISAKMP с OAKLEY и SKEMI (англ. «Secure Key Exchange Mechanism for Internet» – безопасный механизм обмена ключами в Интернет) для решения данной задачи. Сравнивая протоколы SKIP и IKE, надо отметить, что последний более сложен в реализации, но считается более надежным и гибким.

Протокол ISAKMP определяет две фазы согласования параметров взаимодействия:

- согласование глобальных параметров защищенного канала (в терминах IPSec такие параметры называются управляющим контекстом);

- согласование параметров каждого защищенного соединения (они образуют контекст защиты – SA).

С точки зрения модели стека TCP/IP, протокол ISAKMP является протоколом прикладного уровня. В случае его использования совместно с IPSec, спецификация устанавливает использование в качестве протокола нижнего уровня UDP с номером порта 500.

Протокол ISAKMP определяет следующую последовательность действий по формированию управляющего контекста (стороны взаимодействия, например, это могут быть два шлюза безопасности, называются «Инициатор» и «Партнер»):

1) «Инициатор» «Партнер»:заявка на контекст,включающая предлагаемые алгоритмы и их параметры;

2) «Партнер» «Инициатор»:принимаемые алгоритмы и параметры (из списка, полученного на шаге 1; для каждой функции за-щиты – генерация и распределение ключей, шифрование, аутентификация – используется один алгоритм и его параметры);

3) «Инициатор» «Партнер»:ключевой материал и одноразовый номер инициатора;

4) «Партнер» «Инициатор»:ключевой материал и одноразовый номер партнера;

5) «Инициатор» «Партнер»:подписанное инициатором зашифрованное сообщение, содержащее его идентификатор

6) «Партнер» «Инициатор»:подписанное партнером зашифрованное сообщение, содержащее его идентификатор.

Если используется протокол OAKLEY, на шаге 3 и 4 стороны отправляют друг другу свои открытые ключи вместе со случайными числами, служащими для защиты от повтора. Для обеспечения контроля подлинности открытых ключей могут быть использованы сертификаты X.509. В соответствии со схемой Диффи-Хеллмана, рассчитывается общий секретный ключ. На его основе вырабатываются значения:

SKEYID_d –ключевой материал,используемый для генерациивременных ключей для защищенных соединений;

SKEYID_a –сеансовые ключи,используемые для аутентификации сторон и согласовываемых параметров;

SKEYID_e –сеансовые ключи,используемые для шифрованиясогласовываемых параметров.

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

Такой порядок взаимодействия реализуется при использовании основного или базового режима (англ. «Main Mode»). Он более медленный, но и более безопасный. Существует также «агрессивный» режим (англ. «Aggressive Mode») при котором, для увеличения скорости взаимодействия ряд параметров передается в открытом виде и уменьшено число шагов взаимодействия (с 6 до 3 за счет того, что на первом и втором шаге сразу передается больше параметров) [11].

Сообщение ISAKMP состоит из заголовка и следующих за ним полей данных. Формат заголовка приведен на рисунок 3.10.

Рисунок 3.10. Заголовок ISAKMP

Исходя из значения текущего времени, стороны формируют идентификаторы (cookie), которые включают в заголовок пакета (на шаге 1 присутствует только идентификатор стороны-инициатора соединения, на последующих – идентификаторы обеих сторон). Присутствие этих идентификаторов позволяет защититься от атак путем повторных посылок перехваченных сообщений.

Поле «Следующие данные» содержит идентификатор, указывающий на тип содержимого области данных. Например, 1 – контекст защиты (SA), 2 – предложение (используется при согласовании пара-метров); 6 – сертификат, 7 – запрос сертификата и т. д.

Тип обмена –указывает на тип информационного обмена(ре-жим, в котором работает протокол). Например, 0 – нет обмена, 1 – ба-зовый, 4 – агрессивный и т. д.

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

Идентификатор сообщения –уникальный идентификатор со-общения.

Длина –длина сообщения(заголовка и данных).

Итак, описанная фаза протокола позволяет сформировать общий защищенный канал и согласовать его параметры.

После создания общего защищенного канала, параметры каждого защищенного соединения, создаваемого в рамках этого канала, согласуются на основе сформированных глобальных параметров канала и образуют контекст защиты. Каждое защищенное соединение является однонаправленным и в нем может использоваться один из двух протоколов – ESP или AH (кроме того, на базе общего защищенного канала могут быть созданы защищенные соединения, использующие отличный от IPSec протокол). Если предполагается организовать защищаемое ESP двустороннее взаимодействие, понадобятся два соединения (и два SA), если использовать и протокол AH, и ESP, то нужны четыре SA.

В состав согласуемых параметров, образующих SA, входят [13]:

- номер протокола криптозащиты (AH, ESP, другой);

- номера алгоритмов криптозащиты и их параметры;

- режим протокола (транспортный или туннельный);

- сеансовые ключи (действующие для текущего соединения);