Безопасность на сетевом уровне: IP SEC

8.5. Протокол интернет-обмена ключами (IKE)

Протокол Интернет-обмена ключами (IKE - Internet Key Exchange) должен создавать и входящие, и исходящие услуги обеспечения безопасности. Как мы обсуждали в предыдущей секции, когда пакет IP должен быть передан между равными уровнями, тогда обращаются к базе данных стратегии безопасности (SPDB), чтобы видеть, есть ли SA для такого типа трафика. Если нет такой SA, вызывается IKE, чтобы установить ее.

IKE - сложный протокол, основанный на трех других протоколах: OAKLEY, SKEME и ISAKMP, как показано на рис. 8.15.

Рис. 8.15. Компоненты протокола управления ключами в Интернете

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

SKEME, разработанный Хьюго Кравчиком, является другим протоколом для смены ключей. Он использует шифрование открытым ключом для установления подлинности объекта в протоколе смены ключей. Мы коротко рассмотрим, как один из методов, используемых IKE, базируется на SKEME.

Internet-услуги обеспечения безопасности и протокол управления ключами (ISAKMP) являются протоколом, разработанным Агентством Национальной безопасности (NSA), который фактически осуществляет обмен сообщениями, определенными в IKE. Он определяет некоторые пакеты, протоколы и параметры, которые позволяют проводить обмен сообщениями IKE в стандартизированных, отформатированных сообщениях, чтобы создать SA 's. Мы обсудим ISAKMP в следующей секции как протокол, осуществляющий IKE.

В этой секции мы поговорим непосредственно об IKE как о механизме для создания услуг безопасности в SA 's в IPSec.

Улучшенный протокол управления ключами Диффи-Хеллмана

Идея смены ключей в IKE базируется на протоколе Диффи-Хеллмана. Этот протокол обеспечивает ключ сеанса между двумя равными по уровню процессами, без необходимости существования любых предварительных средств безопасности.

В "Управление ключами" мы обсудили метод Диффи-Хеллмана; концепция этого метода суммирована на рис. 8.16.

Рис. 8.16. Обмен ключами по методу Диффи-Хеллмана

В первоначальном методе обмена ключей Диффи-Хеллмана, как показано в лекции 5 (разделе 5.3), две стороны создают симметричный ключ сеанса, чтобы обмениваться данными. При этом им не надо помнить или хранить ключ для будущего использования. Перед установлением симметричного ключа эти две стороны должны выбрать два числа: p и g. Первое число, p, является большим простым числом порядка 300 десятичных цифр (1024 бита). Второе число, g, - генератор в группе.

<Z*_p , x >. Алиса выбирает большое случайное число i и вычисляет KE-I = gⁱ mod p. Она передает KE-I Бобу. Боб выбирает другое большое случайное число r и вычисляет KE-R = gⁱ mod p. Он передает KE-I = gⁱ mod p Алисе. Напоминаем, что KE-I и KE-R, как полуключи метода Диффи-Хеллмана, сгенерированы для равных по уровню процессов. Они должны быть объединены вместе, чтобы создать полный ключ, K = g^ir mod p у. K - это симметричный ключ для сеанса.

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

Засоряющая атака

Первая проблема с протоколом Диффи-Хеллмана - засоряющая атака или атака отказа в обслуживании. Злоумышленник может передать много полуключей ( g^x mod q ) сообщения Бобу, симулируя, что они из различных источников. Тогда Боб должен вычислить различные ответы ( g^y mod q ) и в то же самое время вычислить полный ключ ( g^y mod q ); это загрузит Боба настолько, что он может прекратить отвечать на любые другие сообщения. Он будет отказывать в обслуживании клиентам. Такое может случиться, потому что протокол Диффи-Хеллмана требует большого времени для вычислений.

Чтобы предотвратить атаку засорения, мы можем добавить к протоколу два дополнительных сообщения и вынудить эти две стороны передать cookies

Рис. 8.17 показывает обработку, которая может предотвратить засоряющую атаку. Cookies - результат хэширования уникальных идентификаторов процессов, равных по уровню (таких как адрес IP, число порта и протокол, секретное случайное число, известное сторонам, которые генерирует cookies, и метка времени).

Рис. 8.17. Метод Диффи - Хеллмана с cookies

Инициатор передает собственное cookie; ответная сторона - свой cookie. Оба cookies повторяются в неизмененном виде в каждом последующем сообщении. Вычисления полуключей и ключа сеанса отложены до возвращения cookies. Если любой из процессов этого уровня - хакер, делающий попытку засоряющей атаки, cookies не возвращается; соответствующая сторона не тратит время и усилие на вычисление полуключа или ключа сеанса. Например, если инициатор - хакер, использующий фиктивный адрес IP, инициатор не получает второе сообщение и не может передать третье сообщение. Процесс прерывается.

Атака воспроизведения

Подобно другим протоколам, которые мы рассматривали до сих пор, протокол Диффи-Хеллмана не устойчив к атаке воспроизведения ; информация от одного сеанса может быть записана без расшифровки и воспроизведена в будущем сеансе злоумышленником. Ради предотвращения этой атаки мы можем добавить nonce к третьему и четвертому сообщениям, чтобы сохранить свежесть сообщения.

Атака "посредника"

Третий и наиболее опасный вид атаки протокола Диффи-Хеллмана - атака "посредника", предварительно рассмотренная в "Управление ключами" . Ева может войти в середину диалога и создать один ключ между Алисой и собой и другой ключ между Бобом и собой. Сорвать эту атаку не так просто, как первые две. Мы должны подтвердить аутентификацию каждой стороны.

Алиса и Боб должны убедиться, что сохранена целостность сообщений и что оба аутентифицированы по отношению друг к другу.

Аутентификация обмена сообщений (целостность сообщения) и аутентификация сторон (аутентификация объекта) требует, чтобы каждая сторона доказала, что у нее есть требуемый код идентификации. Чтобы сделать это, каждый должен доказать, что он обладает секретностью.

В IKE секретность может заключаться в одном из следующих сочетаний ключей:

• а. предварительный открытый ключ засекречивания;
• б. предварительно известная пара открытого ключа шифрования/дешифрования. Объект должен показать, что сообщение, зашифрованное объявленным открытым ключом, может быть расшифровано им с помощью соответствующего секретного ключа;
• в. предварительно известная пара открытого ключа цифровой подписи. Объект должен показать, что он может подписать сообщение своим секретным ключом, который может быть проверен его объявленным открытым ключом.

Фазы IKE

IKE создает SA 's для обмена сообщениями протокола, такого как IPSec. IKE, однако, должен обмениваться конфиденциальными и аутентифицированными сообщениями. Какие SA 's обеспечивает протокол IKE для себя? Можно догадаться, что он требует бесконечной цепочки SA 's: IKE должен создать SA 's для IPSec, протокол X должен создать SA 's для IKE, протокол Y должен создать SA 's для протокола X, и так далее. Для того чтобы решить эту дилемму и в то же время оставить IKE независимым от протокола IPSec, разработчики IKE разделили IKE на две фазы. В фазе I IKE создает SA 's для фазы II. В фазе II IKE создает SA 's для IPSec или некоторых других протоколов.

Фаза I является базовой; фаза II задана для протокола.

Однако остается вопрос: как защищена фаза 1? В следующей секции мы покажем, как фаза 1 использует SA, который сформирован постепенно. Более ранние сообщения заменяются в исходном тексте; более поздние сообщения заменяются созданными из ранних сообщений.

Фазы и режимы

Чтобы учесть разнообразие методов обмена, IKE определил для фаз режимы. В настоящее время есть два режима для фазы I: главный режим и энергичный режим. Единственный режим для фазы II - быстрый режим. рис. 8.18 показывает отношения между фазами и режимами.

Рис. 8.18. Фазы IKE

В зависимости от характера предварительной секретности между этими двумя сторонами, режимы фазы I могут использовать один из четырех различных методов аутентификации: метод предварительного открытого ключа засекречивания, метод первоначального открытого ключа, метод пересмотренного открытого ключа или метод цифровой подписи, как это показано на рис. 8.19.

Рис. 8.19. Методы основного или энергичного режима