IKE

IKE (Internet Key Exchange) — стандартный протокол набора протоколов IPsec, используется для обеспечения защищённого взаимодействия в виртуальных частных сетях. Предназначение IKE — защищенное согласование и доставка идентифицирующей информации для "ассоциации безопасности" (SA). Основан на протоколе Oakley.

ИсторияПравить

IKE был изначально определен в ноябре 1998 г. в серии рекомендаций RFC 2407, RFC 2408, RFC 2409.

В декабре 2005 г. вышла вторая версия IKEv2, которая была описана в рекомендации RFC 4306.

В октябре 2014 г. в редакции RFC 7296 вышла исправленная версия стандарта, описывающая IKEv2.

АрхитектураПравить

Протокол передает сообщения через UDP-порты 500 и/или 4500. Установленная SA включает в себя разделяемый секретный ключ и набор криптографических алгоритмов. Также IKE может использовать компрессию IP.

Обмен информацией осуществляется парными сообщениями «запрос — ответ». Такие пары называются «обмен» («exchange»).

Обмен данными в IKE происходит в 2 фазы. В первой фазе устанавливается SA IKE. Во второй - SA IKE используется для согласования протокола (обычно IPSec).

ОпределенияПравить

SKEYID — строка, получаемая из секретного ключа, известного только участникам обмена.

SKEYID_e — материал ключей, используемый SA ISAKMP для защиты конфиденциальности своих сообщений.

SKEYID_a — материал ключей, используемый SA ISAKMP для идентификации своих сообщений.

SKEYID_d — материал ключей, используемый при получении ключей для SA, не относящихся к ISAKMP

Nx — данные текущего времени (x может быть i или r в случае инициатора или получателя соответственно)

prf(key, msg) — псевдослучайная функция с ключом (pseudo-random function). Часто используется хеш-функция.

g^xy — разделяемый секретный код Диффи-Хеллмана.

CKY_x — cookies инициатора (если x == I) или получателя (если x == R) из заголовка ISAKMP

HDR — заголовок ISAKMP. Его поле типа обмена определяет режим. Если пишется HDR*, то данные зашифрованы.

SA — данные согласования, содержащие одно или несколько предложений. Инициатор может отправить несколько предложений, но ответчик обязан ответить только одним предложением.

IDx — данные идентификации для x. В случае, если x == ii, то это данные инициатора в первой фазе, если x == ir, то это данные ответчика в первой фазе, если x == ui, то это данные инициатора во второй фазе, если x == ur, то это данные ответчика во второй фазе.

CERT — данные сертификации.

SIG_X — данные подписи инициатора или ответчика в случае X == I или X == R соответственно.

KE — данные обмена ключами, которые содержат открытую информацию, передаваемую в процессе обмена Диффи-Хеллмана.

HASH(X) — данные хеш-кода.

<X>_b — тело данных X.

<x>y — x зашифрован ключом y.

X | Y — конкатенация X и Y.

Фаза 1Править

Для первой фазы возможны 2 режима: основной и агрессивный.

В основном режиме происходят 3 обмена: в первом узлы договариваются о правилах, во втором обмениваются открытыми значениями Диффи-Хеллмана и вспомогательными данными, в третьем происходит подтверждение обмена Диффи-Хеллмана.

В агрессивном режиме в первом обмене устанавливаются правила, передаются открытые значения Диффи-Хеллмана и вспомогательная информация. Причем во втором сообщении первого обмена происходит идентификация отвечающей стороны (responder). Третье сообщение идентифицирует инициатора и подтверждает участие в обмене. Последнее (четвертое) сообщение может быть не послано.

Для обоих этих методов возможны четыре типа различных методов идентификации: цифровой подписью, два типа шифрования открытым ключом и разделяемый ключ (pre-shared key).

В зависимости от типа идентификации в начале генерируется SKEYID.

SKEYID = prf(Ni_b | Nr_b, g^xy) в случае идентификации цифровой подписью.

SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R) в случае шифрования открытым ключом.

SKEYID = prf(pre-shared-key, Ni_b | Nr_b) в случае разделяемого ключа.

После этого стороны вычисляют материалы ключей SKEYID_d, SKEYID_a, SKEYID_e.

SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)

SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)

SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

Идентификация с помощью цифровой подписиПравить

В основном режиме на этапах 1 и 2 стороны согласовывают SA IKE и договариваются о настройках обмена. Необходимо, чтобы обе стороны передали свои cookies. На 3 и 4 этапах стороны обмениваются ключами Диффи-Хеллмана и псевдослучайными значениями. После этого стороны могут защищать сообщения. На этапах 5 и 6 происходит обмен зашифрованной информацией идентификации.

 

В агрессивном режиме ограничены возможности согласования, так как инициатор должен передать в одном сообщении значения Диффи-Хеллмана и данные текущего времени. А значит инициатор не может предложить разные группы Диффи-Хеллмана. Однако, иногда агрессивный режим может быть единственным способом установления SA IKE, например, если получатель не знает адрес инициатора. Если инициатор уже имеет данные о получателе, то агрессивный режим будет более эффективным.

 

И в основном, и в агрессивном режимах результатом являются подписанные данные (SIG_I и SIG_R).

Идентификация с помощью шифрования открытым ключомПравить

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

 

 

Идентификация с помощью исправленного режима шифрования открытым ключомПравить

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

 

 

Причина возможной отсылки HASH(1) та же что и в простой идентификации с помощью шифрования открытым ключом. Ключи Ke_i и Ke_r согласуются во время обмена данными SA. Данные шифруются, а заголовки данных передаются открытым текстом.

Идентификация с помощью разделяемого ключаПравить

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

 

 

Фаза 2Править

Быстрый режимПравить

Быстрый режим не является полным обменом (так как он неразрывно связан с обменами в 1 фазе), хотя и используется как часть процесса согласования SA, доставляя материалы ключей и согласуя правила для SA, не являющихся ISAKMP SA. Все сообщения должны быть защищены ISAKMP SA. Это значит, что все части сообщений за исключением заголовка ISAKMP шифруются.

 

HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr)

HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr)

HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

Новый материал ключей определяется как:

KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b) — совершенная прямая секретность не требуется

KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) — совершенная прямая секретность требуется. Здесь g(qm)^xy — разделяемый ключ, который был получен в процессе обмена Диффи-Хеллмана.

Режим новой группыПравить

Режим новой группы не должен быть использован до установления SA ISAKMP. Описание новой группы должно следовать только после согласования в фазе 1 (хотя сам режим новой группы не относится к фазе 2).

 

HASH(1) = prf(SKEYID_a, M-ID | SA)

HASH(2) = prf(SKEYID_a, M-ID | SA)

Группы OAKLEYПравить

В группах OAKLEY происходит согласование Диффи-Хеллмана. В RFC 2409 определены 4 группы. Впервые эти группы были описаны в протоколе OAKLEY, поэтому и получили такое название.

ИсточникиПравить

• Блэк У. «Интернет : протоколы безопасности. Учебный курс»
• RFC 2407 — The Internet IP Security Domain of Interpretation for ISAKMP
• RFC 2408 — Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 2409 — The Internet Key Exchange (IKE)