Протокол обмена ключами IKE
Широкое использование IPsec требует масштабируемого, автоматизированного управления контекстами безопасности. Формирование контекстов безопасности по запросу и использование средств защиты от воспроизведения пакетов в протоколах AH и ESP невозможно без работы протокола обмена ключами в Интернете IKE [147]. Протокол IKE разработан на основе протокола управления ключами и контекстами безопасности Интернета - Internet Security Associations and Key Management Protocol (ISAKMP) [146] и протокола вычисления ключей - OAKLEY Key Determination Protocol (OAKLEY) [148]. Протокол ISAKMP обеспечивает независимую от криптографического механизма аутентификацию и задает структуру обмена ключами. Протокол IKE базируется на функциональности протокола ISAKMP, а для формирования симметричного ключа использует возможности протокола OAKLEY. В качестве алгоритма согласования ключей применяется алгоритм Диффи-Хэллмана.
Работа протокола IKE выполняется за два этапа. На первом этапе устанавливается аутентифицируемый и шифруемый канал связи. Это требует формирования двух контекстов безопасности - по одному для связи в одном направлении. Для аутентификации сторон используются сертификаты открытых ключей подписи (в качестве алгоритма цифровой подписи применяется DSA). На втором этапе формируются контексты безопасности для AH и ESP.
Поддержка безопасности IP-уровня на основе PKI
Сертификаты служат главными компонентами аутентификации на основе IKE. Когда идентифицируется хост или защитный шлюз, наиболее предпочтительной формой идентификационных данных являются DNS-имена или IP-адреса, которые указываются в дополнении сертификата Subject Alternative Name (параметры dNSName и iPAddress соответственно). При идентификации пользователя рекомендуется использовать адрес электронной почты или обычное имя. Адрес электронной почты содержится в дополнении сертификата Subject Alternative Name, а обычное имя входит в состав отличительного имени субъекта. Невозможность связать идентичность субъекта с его открытым ключом делает аутентификацию невозможной. Неправильная аутентификация на основе протокола IKE может привести к ложному связыванию ключа и реализации IPsec, в результате неавторизованный пользователь (или даже группа компьютеров) может получить доступ, например, к виртуальной частной сети.
Сертификаты, предназначенные для защиты трафика Интернета, должны включать дополнение Key Usage, которое отражает соответствующее назначение открытого ключа, содержащегося в сертификате (например, цифровая подпись, если необходимо выполнять верификацию подписей). Кроме того, в дополнении сертификата Extended Key Usage должны явным образом указываться те приложения, для поддержки которых предназначен данный открытый ключ, в частности приложение IPsec.
Итак, сертификаты являются базовым компонентом сервисов безопасности, предоставляемых S/MIME, TLS и IPsec.
S/MIME при помощи сертификатов идентифицирует пользователей. Сервисы аутентификации, целостности, неотказуемости и конфиденциальности защищенной электронной почты зависят от сертификатов. Сертификаты поддерживают шифрование и заверение цифровой подписью почтовых сообщений.
TLS при помощи сертификатов идентифицирует пользователей и серверы. От сертификатов зависят сервисы аутентификации, целостности и конфиденциальности. Сертификаты поддерживают шифрование потока, аутентификацию потока и целостность потока.
IPsec при помощи сертификатов идентифицирует пользователей, хосты и шлюзы безопасности. От сертификатов зависят сервисы аутентификации. На базе сертификатов выполняется взаимная аутентификация взаимодействующих сторон при обмене открытыми ключами Диффи-Хэллмана, которые, в свою очередь, используются для безопасного распределения симметричных секретных ключей. Секретные ключи обеспечивают поддержку аутентификации, целостности и конфиденциальности IP-пакетов.
Типовые сценарии использования PKI
В лекциях 3, 4 и 5 обсуждалась архитектура, которую можно назвать полнофункциональной PKI (см. табл. 17.2). Были определены компоненты, функции и сервисы инфраструктуры, которая в некотором смысле является совершенной, потому что теоретически удовлетворяет требованиям любой среды. В конкретной среде целесообразно использовать не общее решение, а только те функции, которые необходимы для решения определенного круга проблем.
Полнофункциональная PKI - это идеальное представление возможной инфраструктуры, пока неизвестны PKI-продукты, реализующие все перечисленные в (таблице 17.2) функции. Современные PKI обычно предназначены для решения определенной задачи или ряда задач. Конкретные реализации PKI представляют собой некоторые подмножества полнофункциональной архитектуры.
|УЦ | Репозиторий | Аннулирование сертификатов |
|Резервное хранение ключей | Восстановление ключей | Автоматическое обновление ключей |
|Управление историями ключей | Кросс-сертификация | Клиентское ПО |
|Аутентификация | Целостность | Конфиденциальность |
|Защищенное датирование | Нотаризация | Неотказуемость |
|Защищенный архив данных | Разработка полномочий/политики | Проверка полномочий/политики |
Таблица 17.2.Полнофункциональная PKI
Рассмотрим четыре распространенных на сегодняшний день сценария использования PKI [44]. В табл. 17.3 представлена Интернет-PKI, которая поддерживает обычную электронную почту (между знакомыми) и навигацию в World Wide Web при помощи SSL-сервера аутентификации. Такой сценарий требует наличия УЦ для выпуска сертификатов открытых ключей и поддержки основных сервисов аутентификации, целостности и конфиденциальности. В этом сценарии не предусмотрено использование репозитория (сертификаты пересылаются по протоколу связи), не выполняется проверка статуса получателя электронной почты (или даже сертификата сервера) и управление жизненным циклом ключей и сертификатов, отсутствует клиентское программное обеспечение (как отдельный модуль, вызываемый при помощи браузера), не требуется ни кросс-сертификация, ни дополнительные сервисы, базирующиеся на PKI.
|УЦ | Репозиторий | Аннулирование сертификатов |
|Резервное хранение ключей | Восстановление ключей | Автоматическое обновление ключей |
|Управление историями ключей | Кросс-сертификация | Клиентское ПО |
|Аутентификация | Целостность | Конфиденциальность |
|Защищенное датирование | Нотаризация | Неотказуемость |
|Защищенный архив данных | Разработка полномочий/политики | Проверка полномочий/политики |
Таблица 17.3.Интернет-PKI
Табл. 17.4 иллюстрирует функции PKI в сценарии, когда для доступа к корпоративной сети извне используется браузер и выполняется SSL-аутентификация клиентов. В этом сценарии должна поддерживаться проверка статуса сертификата, полномочий и политики. Из-за ограниченных возможностей браузера невозможно реализовать управление жизненным циклом ключей и сертификатов, кросс-сертификацию и другие сервисы, базирующиеся на PKI.
|УЦ | Репозиторий | Аннулирование сертификатов |
|Резервное хранение ключей | Восстановление ключей | Автоматическое обновление ключей |
|Управление историями ключей | Кросс-сертификация | Клиентское ПО |
|Аутентификация | Целостность | Конфиденциальность |
|Защищенное датирование | Нотаризация | Неотказуемость |
|Защищенный архив данных | Разработка полномочий/политики | Проверка полномочий/политики |
Таблица 17.4.Экстранет-безопасность (через SSL-аутентификацию клиентов)
В табл. 17.5 представлен набор функций PKI для сценария защищенной корпоративной электронной почты. В этом сценарии может потребоваться управление жизненным циклом ключей и сертификатов и встроенное клиентское программное обеспечение, так как стандартные пакеты электронной почты не всегда поддерживают безопасность, основанную на PKI. В данном случае не нужны дополнительные сервисы, базирующиеся на PKI, и кросс-сертификация.
Наконец, в сценарии поддержки межкорпоративных транзакций с использованием цифровых подписей могут потребоваться многие возможности полнофункциональной PKI, в частности сильная аутентификация и авторизация, проверка статуса сертификатов, разработка и проверка полномочий и политики, сервис неотказуемости (поддержка множественных пар ключей, хранение принятых электронных документов с цифровой подписью и т.д.). Если корпорации имеют свои собственные PKI, то необходима кросс-сертификация. В данном сценарии можно обойтись без архивирования данных, датирования и нотаризации.
