IKEv1 и IKEv2 с общим предварительным ключом: чем отличается аутентификация

Два шлюза, настроенные с одним и тем же предварительным ключом, завершают рукопожатие, и запись пакетов не показывает секрет, пересекающий провод. Это та часть, которую запоминают. Интересна та часть, которую каждая версия действительно вычисляет, чтобы доказать знание секрета, потому что IKEv1 и IKEv2 строят это доказательство из разных входных данных и при этом раскрывают разную информацию. Прочитайте две трассы рядом — и отличие перестанет быть косметическим.

Чего должно достичь доказательство

Diffie-Hellman даёт обеим сторонам общее значение, публичные половины которого может вычислить и любой наблюдатель. Само по себе это ничего не доказывает об идентичности: атакующий, завершивший обмен ключами, имеет то же общее значение, что и ваш шлюз. Шаг аутентификации существует, чтобы привязать этот обмен к секрету, который есть только у предполагаемых сторон, а также к идентичностям и параметрам, о которых они договорились.

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

IKEv1 Main Mode: вывести SKEYID, затем доказать

Main Mode выполняет шесть сообщений. Первая пара согласует ассоциацию безопасности, вторая обменивается открытыми значениями Diffie-Hellman и nonce, третья несёт идентичности и хеши аутентификации под только что установленным шифрованием. RFC 2409 определяет конструкцию: при аутентификации по предварительному ключу SKEYID выводится из секрета и обоих nonce, а последующий ключевой материал — из SKEYID, общего значения Diffie-Hellman, cookie и констант.

Хеш в пятом и шестом сообщениях вычисляется по значению Diffie-Hellman, двум cookie, предложению и идентичности отправителя, с SKEYID в качестве ключа. Получатель пересчитывает его со своим настроенным секретом. Несовпадение завершает обмен, и сам секрет никогда не является полезной нагрузкой.

Aggressive Mode сжимает ту же работу в три сообщения, а значит, идентичности и хеш аутентификации уходят до того, как появится зашифрованный канал. Это реальная экспозиция для угадываемого секрета, и это отдельный вопрос от того, передавался ли секрет. IKEv1 устарел по RFC 9395, поэтому старая трасса — диагностическое упражнение, а не цель развёртывания.

IKEv2: другое выведение и другая полезная нагрузка AUTH

IKEv2 не использует повторно расписание ключей IKEv1. Начальные ключи IKE берутся из зерна, построенного из nonce и общего значения Diffie-Hellman, а дочерние ассоциации безопасности выводятся из него. Предварительный ключ вообще не питает зерно.

Затем аутентификация появляется как полезная нагрузка AUTH. Для аутентификации общим ключом RFC 7296 предписывает дополненную форму секрета, получаемую хешированием секрета с фиксированной строкой Key Pad for IKEv2, а затем хешированием подписанных данных обмена и идентичности этим дополненным ключом. Проверяющая сторона может восстановить то же значение; наблюдатель — нет, без секрета.

Обратите внимание, что изменилось. В IKEv1 секрет замешан в расписание ключей ещё до того, как появляется хеш аутентификации; в IKEv2 расписание ключей не зависит от секрета, а доказательство — отдельная полезная нагрузка, привязанная к подписанным октетам. Та же концептуальная гарантия, другая механика, и поэтому имена параметров и записи не отображаются один к одному.

Что на самом деле узнаёт наблюдатель

Открытые значения Diffie-Hellman, предложения, nonce и cookie видны в обеих версиях. Идентичности видны в IKEv1 Aggressive Mode и защищены в остальных случаях. Секрет не виден никогда.

У последнего предложения есть предел, который стоит назвать. Слабый, выбранный человеком секрет можно атаковать перебором: атакующий вычисляет, каким было бы значение аутентификации для кандидата в секреты, и сравнивает. IKEv1 Aggressive Mode делает это самым дешёвым, потому что доказательство лежит открыто, и стандарты в целом предупреждают о секретах с низкой энтропией. Никогда не передавать секрет — это не то же самое, что сделать плохой секрет безопасным.

Что делать со сравнением

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

Предпочитайте аутентификацию по сертификатам там, где эксплуатационные затраты приемлемы, поскольку она устраняет проблему угадывания общего секрета и даёт каждому участнику отдельную идентичность. Там, где предварительный ключ остаётся, держите его длинным, ограничьте область применения и рассматривайте версию IKE как решение о безопасности, а не как деталь совместимости.