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

Обычно для защищенной связи между двумя абонентами сети требуется 4 ключа: по паре ключейпередачи и приема информации для AH и ESP. IPsec подерживает два типа управления ключами:

• Ручное. Системный администратор вручную конфигурирует каждую систему ее ключей и ключей других сообщающихся с ней систем.

• Автоматизированное. Обеспечивает создание ключей по запросу в автоматическом режиме.

Применяемый по умолчанию в IPsec протокол автоматизированного управления ключами называется ISAKMP/Oakley.

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

ISAKMP (Internet Security Association and Key Management Protocol) обеспечивает схему управления ключами в Интернет и поддержку протокола согласования параметров защиты. Рассмотрим каждый из этих протоколов по-отдельности.

Протокол Oakley

Oakley представляет собой вариант обмена ключами по усовершенствованной схеме Диффи-Хелмана. Схема Диффи-Хелмана описана в разделе 5.3. Эта схема не предполагает никаких действий по проверке идентификаторов обменивающихся сторон, и поэтому может быть подвергнута атаке «третий посередине», когда третья сторона С выступает для А в роли абонента В, а для В – в роли А, и посылает им свои собственные параметры ключей, которыми А и В пользуются в дальнейшем для шифрования данных. Алгоритм Oakley не позволяет выполнить эту атаку путем аутентификации участников обмена. Кроме того, Oakley использует рецепты (cookies) для предотвращения атаки засорения, заключающейся в том, что противник от имени легального участника обмена многократно направляет запрос на генерацию ключей и вызывает загрузку системы получателя лишней работой по выработке параметров процедуры Диффи-Хелмана. Протокол Oakley характеризуется следующими основными моментами:

• использование рецептов

• выбор параметров метода Диффи-Хелмана

• использование оказий для протовостояния атакам воспроизведения

• обмен ключами Диффи-Хелмана

• аутентификация участников обмена

ISAKMP требует, чтобы рецепты, посылаемые инициирующей стороной, могли быть созданы только легальными пользователями. Рекомендуемый метод состоит в том, что рецепт содержит IP адрес источника, номер порта UDP и локально генерируемое секретное значение, сжатые хеш-функцией MD5 или SHA-1.

Oakley поддерживает раличные алгебраические группы для обмена ключами Диффи-Хелмана. На сегодняшний день поддерживаются следующие группы:

1. Возведение в степень в арифметике классов вычетов с 768-битовым модулем:

a = 2

2. Возведение в степень в арифметике классов вычетов с 1024-битовым модулем:

a = 2

3. Возведение в степень в арифметике классов вычетов с 1024-битовым модулем:

параметры определяются пользователем.

4. Группа эллиптической кривой над конечным полем из элементов

• Генератор в шестнадцатиричном виде: X = 7В, Y = 1C8

• Параметры эллиптической кривой в шестнадцатиричном виде: А = 0, Y = 7338F.

5. Группа эллиптической кривой над конечным полем из элементов

• Генератор в шестнадцатиричном виде: X = 18, Y = D

• Параметры эллиптической кривой в шестнадцатиричном виде: А = 0, Y = 1EE9.

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

Пример обмена Oakley

Oakley допускает разные сценарии обмена ключами. Рассмотрим вариант, называемый агрессивным обменом ключами (agressive key exchange). Такое название использовано потому, что требуется всего три обмена сообщениями.

Шаг 1. Инициатор 1 передает получателю 2

• рецепт,

• группу, которую собирается использовать,

• свой открытый ключ Диффи-Хелмана для данного обмена.

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

• идентификаторы – свой и второй стороны

• оказию,

• цифровую подпись, охватывающую все предыдущие поля.

Шаг 2. Получив сообщение, сторона 2 проверяет подпись, используя открытый ключ 1. затем подтверждает сообщение, отсылая назад следущие данные:

• рецепт, идентификатор и оказию, полученые в первом сообщении,

• группу,

• свой открытый ключ Диффи-Хелмана,

• выбранные алгоритмы (из числа предложенных),

• свой идентификатор и оказию для этого обмена,

• цифровую подпись, охватывающую все предыдущие поля.

Шаг 3. Проверяет с помощью открытого ключа 2 соответствие цифровой подписи и сообщения 2. Пересылает обратно последнее сообщение, подписав его своей цифровой подписью (т.е. с использованием своего закрытого ключа).

Протокол ISAKMP

Протокол ISAKMP описан в RFC 2408. Он служит для определения процедур и форматов пакетов для организации, согласования, обновления и удаления ассоциаций безопасности SA (Security Associations). SA содержат все сведения, требуемые для выполнения различных типов сервиса обеспечения безопасности сети (услуги IP-уровня типа аутентификации заголовков и инкапсуляции содержимого, услуги транспортного и прикладного уровней, самообеспечение безопасности трафика согласования параметров). ISAKMP определяет содержимое (payload) обмена при генерации ключей и данных аутентификации. Эти форматы обеспечивают надежный способ обмена ключами и сведениями аутентификации независимо от метода генерации ключей, алгоритма шифрования и механизма аутентификации.

Формат заголовков ISAKMP показан на рисунке:

8	12	16	24	32
Initiator cookie (Рецепт отправителя) (8 байтов)
Responder cookie (Рецепт получателя) (8 байтов)
Следующий элемент	MjVer	MnVer	Тип обмена	Флаги
Идентификатор сообщения
Размер

Структура ISAKMP