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 происходит обмен зашифрованной информацией идентификации.
![Обмен данными при идентификации IKE цифровой подписью в основном режиме фазы 1](http://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/-1-signature_phase1.png/350px--1-signature_phase1.png)
В агрессивном режиме ограничены возможности согласования, так как инициатор должен передать в одном сообщении значения Диффи-Хеллмана и данные текущего времени. А значит инициатор не может предложить разные группы Диффи-Хеллмана. Однако, иногда агрессивный режим может быть единственным способом установления SA IKE, например, если получатель не знает адрес инициатора. Если инициатор уже имеет данные о получателе, то агрессивный режим будет более эффективным.
![Обмен данными при идентификации IKE цифровой подписью в агрессивном режиме фазы 1](http://upload.wikimedia.org/wikipedia/commons/thumb/6/66/-2-signature_phase1.png/350px--2-signature_phase1.png)
И в основном, и в агрессивном режимах результатом являются подписанные данные (SIG_I и SIG_R).
Идентификация с помощью шифрования открытым ключом
Если при работе в основном режиме у ответчика имеется несколько открытых ключей, то в 3-м сообщении пересылается хеш сертификата (HASH(1)), используемого инициатором для шифрования. Таким образом получатель сможет определить, каким ключом шифруются сообщения, просто составляя хеши своих сертификатов и сравнивая их с полученным. Стоит отметить, что данные идентификации и текущего времени шифруются с помощью ключа другой стороны.
![Обмен данными при идентификации IKE с помощью шифрования с открытым ключом в основном режиме фазы 1](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c8/-1-pubkey_phase1.png/350px--1-pubkey_phase1.png)
![Обмен данными при идентификации IKE с помощью шифрования с открытым ключом в агрессивном режиме фазы 1](http://upload.wikimedia.org/wikipedia/commons/thumb/b/bc/-2-pubkey_phase1.png/350px--2-pubkey_phase1.png)
Идентификация с помощью исправленного режима шифрования открытым ключом
Идентификация с помощью шифрования открытым ключом требует затрат на операции с ключами: 2 операции на шифрование открытым ключом и 2 операции на расшифровку закрытым ключом. Исправленный режим позволяет сократить вдвое число операций. В этом режиме данные текущего времени также шифруются при помощи открытого ключа другой стороны, а идентификаторы (и, если отсылаются, сертификаты) шифруются с помощью согласованного симметричного алгоритма шифрования (на основании данных SA). Ключ для этого шифрования получен на основании данных текущего времени.
![Обмен данными при идентификации IKE с помощью исправленного шифрования с открытым ключом в основном режиме фазы 1](http://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/-1-pubkey_rev_phase1.png/350px--1-pubkey_rev_phase1.png)
![Обмен данными при идентификации IKE с помощью исправленного шифрования с открытым ключом в агрессивном режиме фазы 1](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c2/-2-pubkey_rev_phase1.png/350px--2-pubkey_rev_phase1.png)
Причина возможной отсылки HASH(1) та же что и в простой идентификации с помощью шифрования открытым ключом. Ключи Ke_i и Ke_r согласуются во время обмена данными SA. Данные шифруются, а заголовки данных передаются открытым текстом.
Идентификация с помощью разделяемого ключа
Ключ в основном режиме может быть определен по IP-адресу сторон, так как хеш-код инициатора HASH_I должен быть посчитан до того, как инициатор начнет обработку IDir. Агрессивный режим позволяет сторонам иметь несколько разделяемых ключей и при согласовании обмена сообщать какой из них используется.
![Обмен данными при идентификации IKE с помощью разделяемого ключа в основном режиме фазы 1](http://upload.wikimedia.org/wikipedia/commons/thumb/f/f1/-1-preshared_phase1.png/350px--1-preshared_phase1.png)
![Обмен данными при идентификации IKE с помощью разделяемого ключа в агрессивном режиме фазы 1](http://upload.wikimedia.org/wikipedia/commons/thumb/b/b4/-2-preshared_phase1.png/350px--2-preshared_phase1.png)
Фаза 2
Быстрый режим
Быстрый режим не является полным обменом (так как он неразрывно связан с обменами в 1 фазе), хотя и используется как часть процесса согласования SA, доставляя материалы ключей и согласуя правила для SA, не являющихся ISAKMP SA. Все сообщения должны быть защищены ISAKMP SA. Это значит, что все части сообщений за исключением заголовка ISAKMP шифруются.
![Обмен данными во время второй фазы IKE в быстром режиме](http://upload.wikimedia.org/wikipedia/commons/thumb/1/14/-1-quick_mode_phase2.png/350px--1-quick_mode_phase2.png)
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).
![Обмен данными в IKE в режиме новой группы](http://upload.wikimedia.org/wikipedia/commons/thumb/0/04/-1-new_group.png/350px--1-new_group.png)
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)