IPsec, IKE и смежные технологии Рябко С.Д., к.ф.-м.н. СТАНДАРТ СЕТЕВОЙ БЕЗОПАСНОСТИ ДЛЯ РОССИЙСКОГО БИЗНЕСА Cisco Solution Technology Integrator IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература Предпосылки и требования Cisco Solution Technology Integrator Безопасность ... задолго до TCP IP Paul Baran. RAND MEMORANDUM RM-3765-PR, AUGUST 1964. On Distributed Communications: IX Security, Secrecy, and Tamper-Free Considerations DTE DCE L2-шифрование L3-шифрование © 2003-2007 S-Terra CSP 3 Проблемы безопасности TCP/IP TCP/IP проектировался, как коммуникационный протокол с целями: - надежной передачи данных через гетерогенные физические среды - контроля связности сети и маршрутизации - оптимизации загрузки, адаптации транспортных сервисов к условиям сети TCP/IP ИЗНАЧАЛЬНО НЕ ПРОЕКТИРОВАЛСЯ КАК ЗАЩИЩЕННАЯ КОММУНИКАЦИОННАЯ СРЕДА Результаты: - IP-атаки ICMP-атаки атаки на системы маршрутизации UDP- и TCP-атаки атаки на уровне прикладных протоколов © 2003-2007 S-Terra CSP 4 IPsec, зачатие BOF-сессия IETF в Бостоне в 1992 году, Элтон Гувер (Alton Hoover): - «Протокол защиты сетевого уровня будет создан, чтобы обеспечить криптографические сервисы защиты: аутентификацию, целостность, контроль доступа и конфиденциальность. Первоначальными целями будет поддержка взаимодействия между компьютерами, вслед на тем – между двумя подсетями и между компьютером и подсетью» © 2003-2007 S-Terra CSP 5 Требования к протоколам защиты 1. Аутентификация, целостность, контроль доступа и конфиденциальность 2. Cеть-сеть, клиент-сеть, клиент-сервер (др. клиент) 3. Нейтральность по отношению к криптоалгоритмам 4. Независимость мастер-ключа и временного ключа 5. Пересинхронизация ключевых контекстов - по мере накопления статистики для криптоанализа по событиям 6. Целостность потока пакетов уход от дейтаграммной природы IP, контекст соединения, SA © 2003-2007 S-Terra CSP 6 Требования по управлению ключами 1. Установление ключа (key establishment) – генерация ключа и доставка его потребителю 2. Аутентификация – поддержка множества механизмов аутентификации: симметричный ключи и сертификат, одноразовый пароль и серверы аутентификации (RADIUS и т.п.), произвольные комбинации этих механизмов 3. Симметрия – равная способность каждой из сторон создать ключ для защищенного обмена; относительная устойчивость к DoS-атаке 4. Защита сеансового ключа (perfect forward secrecy) 5. Независимость сеансовых ключей (back traffic protection) 6. Согласование политик безопасности сторон 7. Расширяемость (payload, domain of interpretation) © 2003-2007 S-Terra CSP 7 © 2003-2007 S-Terra CSP IETF-36, 24-28.VI.1996 IETF-35, 4-8.III.1996 1995 IETF-34, 4-8.XII.1995 (нет информации) IETF-33, 17-21.VII.1995 IETF-32, 3-7.IV.1995 1994 IETF-31, 5-9.XII.1994 IETF-30, 25-29.VII.1994 IETF-29, 28.III-1.IV.1994 Oakley RFC 1825-1829 ISAKMP Photuris SKIP История группы IPsec в IETF 1993-1996 40 Общее число рассмотренных предложений 20 Новые спецификации на текущей сессии 0 1996 8 IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература Архитектура IPsec Cisco Solution Technology Integrator IPsec. Основные стандарты RFC 2402 «IP Authentication Header» (AH) – обеспечивает целостность и аутентификацию передаваемых пакетов, целостность потока пакетов RFC 2406 «IP Encapsulating Security Payload» (ESP) – обеспечивает конфиденциальность (шифрование), целостность и аутентификацию источника данных передаваемых пакетов, ограниченную конфиденциальность потока данных, защиту от повторно переданного пакета - © 2003-2007 S-Terra CSP протоколы AH и ESP могут использоваться совместно или по отдельности RFC 2408 «Internet Security Association and Key Management Protocol» (ISAKMP) - обеспечивает согласование параметров, создание, изменение, уничтожение контекстов защищенных соединений (далее – Security Association, SA) и управление ключами RFC 2409 «The Internet Key Exchange» (IKE) – развитие (адаптация) ISAKMP для работы с протоколами IPsec 10 Туннельный и транспортный режимы Протоколы IPsec работают в двух режимах: транспортном (взаимодействие хостов) и туннельном (взаимодействие с подсетями) Транспортный режим - ниже вычислительные и коммуникационные накладные недостатки: • • Туннельный режим - - © 2003-2007 S-Terra CSP невозможность скрыть топологию сети ESP в транспортном режиме не защищает заголовок IP-пакета взаимодействие сеть-сеть, хостсеть, возможно также – хост-хост скрывает топологию сети, поскольку снаружи выставляется другой заголовок (а исходный шифруется) потребляет несколько больше ресурсов 11 IPsec. Протокол AH © 2003-2007 S-Terra CSP Аутентификация источника и данных каждого IP пакета (является эффективным методом борьбы с атаками типа перехвата, модификации трафика и подмены IP адресов) Целостность данных IP пакетов, данные пакетов передаются в незашифрованном виде Защита от повторной передачи пакетов 12 IPsec. Протокол AH При расчете значений хеш-сумм для контроля целостности данных (integrity check value, ICV) не используются переменные поля IP-заголовка оригинального пакета AH заголовок увеличивает длину оригинального IP пакета приблизительно на 24 байта Криптографические алгоритмы хеширования поддерживаемые протоколом AH: - обязательные (для обеспечения совместимости продуктов различных производителей): программных • HMAC-MD5-96 (RFC 2403) • HMAC-SHA-1-96 (RFC 2404) - дополнительные: • DES-MAC • HMAC-ГОСТ Р 34.11-94, -2001 Протокол AH может использоваться в туннельном или транспортном режимах, а также в комбинации с протоколом ESP © 2003-2007 S-Terra CSP 13 IPsec. Протокол ESP Протокол ESP обеспечивает: - шифрование данных IP пакета - дополнительно (аналогично протоколу AH): • аутентификацию источника каждого IP пакета • целостность данных IP пакетов • защиту от повторной передачи пакетов © 2003-2007 S-Terra CSP 14 IPsec. Протокол ESP ESP заголовок увеличивает длину оригинального IP пакета приблизительно на 24 байта Протокол ESP поддерживает криптографические алгоритмы шифрования: - обязательные: • DES-CBC (RFC 2405) • NULL (RFC 2410) - дополнительные: • • • • • CAST-128 (RFC 2451) IDEA (RFC 2451) 3DES (RFC 2451) AES- 128, 192, 256 ГОСТ (ГОСТ 28147-89) Протокол ESP поддерживает криптографические алгоритмы хэширования: - обязательные: • HMAC-MD5-96 (RFC 2403) • HMAC-SHA-1-96 (RFC 2404) - дополнительные: • DES-MAC • HMAC-ГОСТ Р 34.11-94 , -2001 Протокол ESP может использоваться в туннельном или транспортном режимах, а также в комбинации с протоколом AH © 2003-2007 S-Terra CSP 15 AH и ESP в транспортном режиме © 2003-2007 S-Terra CSP 16 AH и ESP в туннельном режиме © 2003-2007 S-Terra CSP 17 Контекст безопасности, IPsec SA Контекст безопасности IPsec, Security Association, SA – это структура данных, которая организуется при помощи протокола IKE для защиты трафика в каждом из направлений - контекст безопасности уникальным образом определяется, как комбинация Security Parameter Index (SPI), IP Destination address и идентификатор протокола AH/ESP Контексты безопасности соответствуют режиму AH/ESP – транспортный или туннельный В случае, если необходимо создать сложную политику безопасности, которую невозможно описать при помощи одного контекста (SA), используется «связка контекстов» (SA bundle). Связки SA применяются для двух целей: - в транспортном режиме – для применения одновременно протоколов AH и ESP - в туннельном режиме – для создания вложенных туннелей, которые могут терминироваться в различных точках сети © 2003-2007 S-Terra CSP 18 Целостность потока пакетов Целостность пакетов в потоке обеспечивается механизмами IPsec AH или IPsec ESP-auth - эти же механизмы отсекают «чужой» или «свой», модифицированный злоумышленником, пакет КАК ЗАЩИТИТЬСЯ ОТ ПОВТОРНОЙ ПЕРЕДАЧИ СВОЕГО ПАКЕТА? - счетчик пакетов 232 (при инициализации SA устанавливается в 0 и инкрементируется для каждого последующего пакета) - поскольку пакеты в IP-сети могут переупорядочиваться, дуплицироваться и теряться – оконное управление потоком © 2003-2007 S-Terra CSP 19 Основные преимущества IPsec Прозрачность для любых приложений Полный контроль входящего/исходящего трафика - IPsec драйвер размещен в нижней части драйвера, реализующего IP протокол Защита от большинства сетевых атак, включая DoS Высокая производительность - используются симметричные криптографические алгоритмы Большое количество сценариев защиты - сочетание AH и ESP протоколов - туннельный и транспортный режимы © 2003-2007 S-Terra CSP 20 IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература Протокол IKE Cisco Solution Technology Integrator Протокол IKE Протоколы IPsec AH и ESP не самодостаточны в том смысле, что требуют поставки ключевого материала и политики «извне» Протокол IKE обеспечивает IPsec необходимыми ключами и согласованной политикой Протокол IKE – разработан в развитие протоколов ISAKMP, Oakley и SKEME - полностью защищен - расширяем (может применяться для конфигурирования адресов, передачи абстрактных данных - Vendor ID, keep alive и т.п.) - обеспечивает строгую взаимную аутентификацию партнеров © 2003-2007 S-Terra CSP 22 Функции протокола IKE Протокол IKE обеспечивает: - создание ключевого криптографического материала и взаимную аутентификацию партнеров по взаимодействию при ключевом обмене - создание контекстов защищенных взаимно аутентифицированных соединений (ISAKMP Security Association, ISAKMP SA) для обмена ключевой/аутентификационной информацией – первая фаза протокола IKE - согласование параметров (политик) защищенных соединений (IPsec Security Association, IPsec SA) для обмена данными – вторая фаза протокола IKE - автоматическую замену криптографических ключей по задаваемому перечню событий или компрометации - защиту сеансовых криптографических ключей (Perfect forward secrecy, PFS) - строгую взаимную аутентификацию партнеров по взаимодействию © 2003-2007 S-Terra CSP 23 Фазы и режимы протокола IKE Протокол IKE формально разделен на две фазы Первая фаза может быть реализована в двух разных режимах: - Main Mode • более сложен, но при этом более гибок и обеспечивает анонимность участников (identity protection) - Aggressive Mode В рамках первой фазы создается контекст защищенного соединения ISAKMP SA, все дальнейшие информационные обмены производятся под его защитой - однажды созданный на первой фазе контекст ISAKMP SA может использоваться для нескольких вторых фаз, таким образом, на его основе может быть создано несколько IPsec SA © 2003-2007 S-Terra CSP 24 Фазы и режимы протокола IKE (продолжение) Вторая фаза реализована в Quick Mode На второй фазе производится: - обновление ключевого материала для обеспечения защищенного обмена данными в рамках IPsec AH и/или ESP - согласование параметров IPsec SA - защита сеансовых криптографических ключей (Perfect forward secrecy, PFS) Для согласования параметров «собственной» группы DH должна быть использована New Group Mode, которая должна следовать сразу за первой фазой, но не является частью Quick Mode Контекст соединения - ISAKMP SA двунаправленный, т.е. в его рамках любой из участников взаимодействия может быть инициатором Quick Mode, New Group Mode и информационных обменов (Informational Exchanges) © 2003-2007 S-Terra CSP 25 Структура обменов в IKE Задача любой фазы (Main, Aggressive и Quick Modes) – согласовать параметры взаимодействия, обменяться открытыми ключами DH и аутентифицировать ключевой обмен Согласование параметров производится в рамках обменов (Exchange) структурированными (стандартизованными) сообщениями (Message) Каждое сообщение формализовано как набор вложенных структур данных (Payload) © 2003-2007 S-Terra CSP 26 Первая фаза протокола IKE, Main Mode Согласование параметров ISAKMP SA - сообщения 1, 2: - Обмен открытыми ключами DH и служебными данными (Nonces) – сообщения 3, 4 Расчет ключевого материала для процедур шифрования и аутентификации в рамках ISAKMP SA Взаимная аутентификация – сообщения 5, 6 - © 2003-2007 S-Terra CSP метод аутентификации время жизни ISAKMP SA группа DH алгоритм хэширования алгоритм шифрования в Main Mode аутентификационная информация передается в зашифрованном виде Дальнейшие информационные обмены производятся под защитой созданного контекста (SA) 27 Первая фаза IKE, Aggressive Mode Выбор между безопасностью и производительностью Как и в Main Mode партнеры должны согласовать: - метод аутентификации время жизни ISAKMP SA группу DH алгоритм хэширования алгоритм шифрования Произвести обмен открытыми ключами DH и служебными данными и расчет ключевого материала Провести взаимную аутентификацию - аутентификационная информация передается в открытом виде © 2003-2007 S-Terra CSP 28 Методы аутентификации В рамках протокола IKE стандартизованы четыре метода аутентификации: - на предопределенных ключах - with a Pre-Shared Key - на электронной цифровой подписи - with Signature - шифрование на открытых ключах • with Public Key Encryption • with a Revised Mode of Public Key Encryption - наиболее широко используемые методы – на предопределенных ключах и ЭЦП © 2003-2007 S-Terra CSP 29 Вторая фаза протокола IKE, Quick Mode Вторая фаза протокола IKE реализуется в Quick Mode - согласование параметров IPsec SA - обновление ключевого материала для обеспечения защищенного обмена данными в рамках IPsec AH и/или ESP - защита сеансовых криптографических ключей (Perfect forward secrecy, PFS) © 2003-2007 S-Terra CSP 30 IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература Применения Cisco Solution Technology Integrator Роль и место IKE/IPsec Что мне лучше использовать – защиту сетевого, транспортного и прикладного уровня? - И то, и другое, и третье, но в разных сценариях - Защита сетевого уровня нужна там, где требуется создать изолированную доверенную среду предприятия, единую для всех приложений - Защита транспортного уровня пригодится там, где у Вас нет возможности установить для всех пользователей VPN-клиента, например, в задачах защиты доступа граждан к порталу госорганов или в задачах электронной коммерции - Защита прикладного уровня незаменима при работе с электронными документами © 2003-2007 S-Terra CSP 32 L3 или L4 VPN? Равнозначны (равнозащищены) ли технологии VPN сетевого (IPsec) и транспортного (SSL, TLS) уровней? - С точки зрения стойкости криптографий – да - С точки зрения дизайна криптографических протоколов предпочтение экспертов принадлежит IKE/IPsec (The Burton group) - По целям дизайна протоколы 4го уровня рассчитаны на защиту отдельного приложения (защита транспортного соединения порт-порт в системе клиент-сервер). Другие порты на том же сервере могут быть открыты (и атакованы). VPN сетевого уровня может защитить сетевую инфраструктуру или сервер в целом • Однако в последнее время появились и приобретают популярность «шлюзовые» L4 VPN-продукты, которые «умеют» инкапсулировать IP-трафик в SSL/TLS. Такие продукты функционально практически эквивалентны L3 VPN с двумя отличиями: (1) функциональность протокола управления ключами в SSL/TLS много уступает IKE и (2) поскольку это – «нетрадиционное» использование протокола на сегодня «шлюзовые» продукты L4 VPN от разных производителей плохо совместимы между собой © 2003-2007 S-Terra CSP 33 IPsec в «реальной сети» Как работает IPsec AH при наличии NAT? (Целостность заголовка противоречит трансляции адресов) - В хороших реализациях IKE/IPsec – без проблем. IKE автоматически детектирует NAT на пути туннеля и включает режим «NAT traversal IPsec» Как обстоят дела с фрагментацией? - Корректный VPN-продукт умеет фрагментировать/ дефрагментировать шифрованный трафик. Однако при этом производительность шифрования падает. Рекомендуется настройка MTU «с запасом» на заголовки IPsec Насколько повышают общую защищенность системы контроля целостности ESP-auth и AH? - Полезная функция, однако может приводить к «узкому горлу» в производительности. Поэтому ряд наших заказчиков устраивает политика безопасности, когда для защиты трафика используется IPsec ESP, а целостность потока данных «обеспечивает» TCP - Также интересным является решение, когда целостность обеспечивается на «внешних» маршрутизаторах на базе IPsec AH/MD5, а конфиденциальность – во внутреннем периметре на базе IPsec ESP/ГОСТ © 2003-2007 S-Terra CSP 34 Какова избыточность протоколов IPsec? Зависит от политики безопасности и криптографии. Расчет Кирилла Корнилова (для IPv4): - Протокол AH: • 12 байт + длина digest, все это округляется кратного 4 в большую сторону, если туннель - еще +20 байт • длина digest: • HMAC 96 (SHA1, MD5, ГОСТ) - 12 байт (полное увеличение пакета – 24..44) • KPDK (MD5) - 16 байт (полное увеличение пакета – 28..48) - Протокол ESP: • • • • • • • 8 байт + длина IV + длина digest + 2 байта, длина шифрованных данных дополняется до блока алгоритма если туннель - еще +20 байт если NAT traversal - еще +8 байт если нет integrity - длина digest = 0 если нет шифрования - длина блока = 1, длина IV = 0 Длина IV, длина блока: • DES, 3DES, ГОСТ - 8 байт • AES - 16 байт • Например, ESP/ГОСТ без integrity, туннельный режим, без NAT traversal увеличивает пакет на 38..45 байт © 2003-2007 S-Terra CSP 35 Еще пара вопросов Нужен ли IPcomp? - по нашему опыту статистическая база пакета не дает возможности обеспечить его существенное сжатие - Cisco не рекомендует IPcomp по причинам снижения производительности (при малой эффективности сжатия) и плохой совместимости ПО Совместимы ли VPN-продукты различных производителей? - В базовых протоколах IKE/IPsec – да. Однако из-за несовместимости дополнительных спецификаций и различной инфраструктуры/логики управления целесообразно минимизировать количество используемых VPN-продуктов © 2003-2007 S-Terra CSP 36 IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ Предпосылки и требования Архитектура IPsec Протокол IKE Применения Литература Литература Cisco Solution Technology Integrator Источники разработки 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. RFC 2401, Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November 1998 RFC 2402, IP Authentication Header. S. Kent, R. Atkinson. November 1998 RFC 2403, The Use of HMAC-MD5-96 within ESP and AH. C. Madson, R. Glenn. November 1998 RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn. November 1998 RFC 2405, The ESP DES-CBC Cipher Algorithm With Explicit IV. C. Madson, N. Doraswamy. November 1998 RFC 2406, IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. November 1998 RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP. D. Piper. November 1998 RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November 1998 RFC 2409, The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November 1998 RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, S. Kent. November 1998 RFC 2411, IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. November 1998 RFC 2412, The OAKLEY Key Determination Protocol. H. Orman. November 1998 Московиц Р. Протокол IPSec для групп по интересам // Network Computing. - 2000. - №11. Busby M. Demystifying Virtual Private Networks. Wordware Publishing, Inc. 2001. 249 p. A Comprehensive Guide to Virtual Private Networks, Volume II: IBM Nways Router Solutions. IBM. International Technical Support Organization SG24-5234-01. November 1999. 642 p. Davies C.R. IPSec: Securing VPNs. Osborne/McGraw-Hill, 2001. - 404 p. Using IPSec to Construct Secure Virtual Private Networks. International Business Machines Corporation. 1998. 61 p. © 2003-2007 S-Terra CSP 38 КОНТАКТЫ e-mail: information@s-terra.com web: http://www.s-terra.com/ Тел.: +7 (495) 531 9789 +7 (495) 726 9891 Факс: +7 (495) 531 9789 Вопросы? Обращайтесь к нам! Cisco Solution Technology Integrator