Я делал IPsec VPN на ASA 8.0, и я немного понимаю об этом. Инициатор начинает с отправки своей политики ISAKMP ответчику, а ответчик отправляет обратно соответствующую политику. После этого ключ Диффи-Хеллмана получает обмен, а затем оба отправляют предварительный общий ключ другому для аутентификации.
Теперь у нас есть два ключа:
Какой ключ используется для шифрования предварительного общего ключа?
Ответы:
Вы задали отличный вопрос. Вопрос кажется очень простым, но на самом деле ответ несколько сложнее. Я сделаю все возможное, чтобы ответить на него в сжатой форме. Кроме того, поскольку вы упомянули ISAKMP, я предполагаю, что вы заинтересованы в IKEv1. Ситуация немного изменилась для IKEv2 (ну, очень), но я хотел бы упомянуть, что ответ ниже относится только к IKEv1.
Этап 1 может быть выполнен в двух разных модах: Основной режим и Агрессивный режим. В любом режиме первое сообщение отправляется Инициатором, а второе сообщение отправляется Ответчиком. Оба эти сообщения включают в себя то, что известно в мире криптографии как Nonce . Одноразовый номер - это просто случайное число, используемое для генерации ключей. (термин Nonce происходит от _N_umber, использованного _Once_) . Итак, после сообщения 1 и сообщения 2 обе стороны знают одноразовые номера друг друга.
Nonce объединяются с Pre-Shared-Key для создания значения Seed для генерации секретных ключей. Относительная часть IKE RFC здесь:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID - это значение Seed, которое позже будет использовано для создания дополнительных секретных ключей. Pre-Shared-Key и оба значения Nonce (Ni_b - одноразовый номер инициатора, а Nr_B - одноразовый номер ответчика) объединяются с использованием PRF или случайной функции Psuedo. PRF похож на алгоритм хеширования, за исключением того, что результат может содержать столько бит, сколько вам нужно.
Теперь, если вы изначально работали в основном режиме, сообщения 3 и 4 совместно используют открытые ключи Диффи-Хеллмана Инициатора и Ответчика (соответственно). Они оба используют эти значения для генерации общего секрета Диффи-Хеллмана . Если вы работали в агрессивном режиме, эти общедоступные значения DH также включены в Сообщение 1 и Сообщение 2 (вместе с Одноразовыми номерами).
Затем значение Seed объединяется с общим секретом DH (и несколькими другими значениями) для создания трех ключей сеанса : ключа отмены, ключа аутентификации и ключа шифрования. RFC утверждает это так:
Результатом основного режима или агрессивного режима являются три группы аутентифицированного ключевого материала:
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)
SKEYID_d, _a и _e - три упомянутых выше ключа сеанса. SKEYIDэто значение семени. g^xyявляется общим секретом DH. CKY-Iи CKI-Rэто файлы cookie Инициатора и Ответчика, это просто дополнительные случайно сгенерированные значения, которые позже используются для идентификации этого конкретного обмена ISAKMP и ассоциации безопасности. 0 1 2являются буквальными числами 0, 1 и 2. Символ трубы |представляет конкатенацию.
В любом случае все эти значения объединяются с использованием PRF, который создает три ключа сеанса:
Ключ аутентификации и ключ шифрования используются для защиты / шифрования последующего согласования фазы 2. В основном режиме сообщения 5 и 6 фазы 1 также защищены этими ключами. Кроме того, любые будущие информационные обмены ISAKMP (DPD, события Rekey, сообщения Delete и т. Д.) Также защищены этими двумя ключами.
Производный ключ передается IPsec, и IPsec генерирует свой собственный материал ключей из этого ключа. Если вы помните, IPsec не включает в себя механизм обмена ключами, поэтому единственный способ получить секретные ключи - это либо установить их вручную (что архаично, но больше никогда не выполняется), либо ИЛИ полагаться на внешнюю службу для предоставить материал для ввода, например, ISAKMP.
RFC говорит это так:
SKEYID_e - материал ключей, используемый ISAKMP SA для защиты конфиденциальности своих сообщений.
SKEYID_a - это материал ключей, используемый ISAKMP SA для аутентификации своих сообщений.
SKEYID_d - это материал ключей, используемый для получения ключей для ассоциаций безопасности не-ISAKMP.
После всего сказанного мы можем вернуться к вашему вопросу: какой ключ используется для защиты предварительного общего ключа?
В основном режиме предварительный общий ключ (PSK) проверяется в сообщениях 5 и 6. Сообщения 5 и 6 защищены сессионными ключами, которые генерирует ISAKMP, как описано выше.
В агрессивном режиме ни одно из сообщений в согласовании не шифруется. И PSK проверяется в сообщениях 2 и 3. Обратите внимание, я сказал , в обеих случаях PSK является проверенными , и я никогда не говорил , что это PSK обмена . Очевидно, что если в Агрессивном режиме ничего не зашифровано, и вы просто отправили Pre-Shared-Key по проводу в незашифрованном виде, была бы огромная зияющая уязвимость безопасности.
К счастью для нас, авторы ISAKMP уже думали об этом. И в результате они создали специальный метод для проверки того, что каждая сторона имеет правильный PSK, фактически не передавая его по проводам. Есть два элемента, которые использовать для проверки каждой Peer , что они оба имеют один и тот же ключ PSK: в удостоверениях методу и удостоверения Hash .
VPN Peers могут выбрать для идентификации себя различными методами; чаще всего одноранговые узлы просто используют свой IP-адрес источника. Но у них есть возможность использовать полное доменное имя или имя хоста. Каждый из них, наряду с коррелирующим значением для выбранного метода, составляют метод идентификации. Так, например, если бы у меня был IP 5.5.5.5, и я хотел использовать свой IP-адрес, чтобы идентифицировать себя, мой метод идентификации был бы [IP Address, 5.5.5.5] . (Примечание: оба значения составляют весь метод идентификации)
Затем метод ID объединяется (с использованием PRF) со значением Seed, которое мы обсуждали ранее (SKEYID), и несколькими другими значениями, чтобы создать хэш Identity . Напомним, что прежде всего при создании SKEYID использовался Pre-Shared-Key.
Метод идентификатора и идентификатор хэша затем отправляются по сети, и другая сторона пытается воссоздать идентификатор хэша, используя ту же формулу. Если получатель может воссоздать тот же хэш идентификатора, он докажет получателю, что у отправителя должен быть правильный предварительный общий ключ.
Это описано в RFC здесь:
Для аутентификации любого обмена инициатор протокола генерирует HASH_I, а ответчик генерирует HASH_R, где:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDii и IDir - это метод идентификации. И HASH_I и HASH_R - это хэш инициатора и ответчика. Оба из них являются общими в Phase1. Из RFC:
При выполнении аутентификации с предварительным общим ключом основной режим определяется следующим образом:
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_RАгрессивный режим с предварительным общим ключом описывается следующим образом:
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
И теперь мы можем наконец ответить на ваш вопрос полностью:
Pre-Shared-Key комбинируется с использованием PRF с одноразовыми номерами и кучей других значений, известных любому другому в процессе переговоров. Результатом является значение, которое может быть достигнуто взаимно только двумя сторонами, если обе стороны начали с одних и тех же значений - иначе говоря, одного и того же предварительного ключа. Результирующее значение - это то, что совместно используется по проводам, что позволяет двум сторонам проверять наличие соответствующих предварительных ключей без фактического раскрытия какой-либо информации о самом предварительном ключе.
Основной режим становится еще более безопасным за счет шифрования обмена «результирующим значением», описанным выше, что еще более затрудняет извлечение какой-либо полезной информации о том, чем был Pre-Shared-Key.
(кажется, я с треском провалился, ответив кратко)
Ваш ответ на ваш вопрос: обмен Диффи-Хеллмана используется для генерации общего ключа для безопасного обмена общим ключом (т. Е. Предварительного обмена).
Смотрите это: /security/67953/understanding-diffie-hellman-key-exchange