краткая историческая справка появления протокола
В 1994 году Совет по архитектуре Интернет (IAB) выпустил отчет "Безопасность архитектуры Интернет". В этом документе описывались основные области применения дополнительных средств безопасности в сети Интернет, а именно защита от несанкционированного мониторинга, подмены пакетов и управления потоками данных. В числе первоочередных и наиболее важных защитных мер указывалась необходимость разработки концепции и основных механизмов обеспечения целостности и конфиденциальности потоков данных. Поскольку изменение базовых протоколов семейства TCP/IP вызвало бы полную перестройку сети Интернет, была поставлена задача обеспечения безопасности информационного обмена в открытых телекоммуникационных сетях на базе существующих протоколов. Таким образом, начала создаваться спецификация Secure IP, дополнительная по отношению к протоколам IPv4 и IPv6.
архитектура IPSec
IP Security - это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC.
Спецификация IP Security (известная сегодня как IPsec) разрабатывается рабочей группой IP Security Protocol IETF. Первоначально IPsec включал в себя 3 алгоритмо-независимые базовые спецификации, опубликованные в качестве RFC-документов "Архитектура безопасности IP", "Аутентифицирующий заголовок (AH)", "Инкапсуляция зашифрованных данных (ESP)" (RFC1825, 1826 и 1827). Необходимо заметить, что в ноябре 1998 года Рабочая группа IP Security Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов, это RFC2401 - RFC2412. Отметим, что RFC1825-27 на протяжении уже нескольких лет считаются устаревшими и реально не используются. Кроме этого, существуют несколько алгоритмо-зависимых спецификаций, использующих протоколы MD5, SHA, DES.
Рис.1. Архитектура IPSec
Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка Internet Key Management Protocol (IKMP), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием спецификации Internet Security Association and Key Management Protocol (ISAKMP) и протокола Oakley Key Determination Protocol. Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Ранее рассматривались также возможности использования механизмов управления ключами протокола SKIP, однако сейчас такие возможности реально практически нигде не используются. Создаваемые стандарты управления ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos. Протоколами ключевого управления для IPSec на основе Kerberos сейчас занимается относительно новая рабочая группа KINK (Kerberized Internet Negotiation of Keys).
Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного обмена т.н. "контекста безопасности" - применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией и их параметров. Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом согласования контекста безопасности является установление индекса параметров безопасности (SPI), представляющего собой указатель на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности.
По сути, IPSec, который станет составной частью IPv6, работает на третьем уровне, т. е. на сетевом уровне. В результате передаваемые IP-пакеты будут защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.
Рис.2. Модель OSI/ISO
К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе Data Encryption Standard (DES) и Message Digest 5 (MD5).
Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты, такие как алгоритмы аутентификации и ключи. IPSec поддерживает два типа схем управления ключами, с помощью которых участники могут согласовать параметры сеанса. Эта двойная поддержка в свое время вызвала определенные трения в IETF Working Group.
С текущей версией IP, IPv4, могут быть использованы или Internet Secure Association Key Management Protocol (ISAKMP), или Simple Key Management for Internet Protocol. С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как IKE, хотя не исключается возможность использования SKIP. Однако, следует иметь в виду, что SKIP уже давно не рассматривается как кандидат управления ключами, и был исключен из списка возможных кандидатов еще в 1997 г.
заголовки AH и ESP
аутентифицирующий заголовок AH
Аутентифицирующий заголовок (AH) является обычным опциональным заголовком и, как правило, располагается между основным заголовком пакета IP и полем данных. Наличие AH никак не влияет на процесс передачи информации транспортного и более высокого уровней. Основным и единственным назначением AH является обеспечение защиты от атак, связанных с несанкционированным изменением содержимого пакета, и в том числе от подмены исходного адреса сетевого уровня. Протоколы более высокого уровня должны быть модифицированы в целях осуществления проверки аутентичности полученных данных.
Формат AH достаточно прост и состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей достаточно ясно отражают их содержимое: Next Header указывает на следующий заголовок, Payload Len представляет длину пакета, SPI является указателем на контекст безопасности и Sequence Number Field содержит последовательный номер пакета.
Рис.3. Формат заголовка AH
Последовательный номер пакета был введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Поскольку сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (обычно это число равно 64).
В отличие от алгоритмов вычисления контрольной суммы, применяемых в протоколах передачи информации по коммутируемым линиям связи или по каналам локальных сетей и ориентированных на исправление случайных ошибок среды передачи, механизмы обеспечения целостности данных в открытых телекоммуникационных сетях должны иметь средства защиты от внесения целенаправленных изменений. Одним из таких механизмов является специальное применение алгоритма MD5: в процессе формирования AH последовательно вычисляется хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям.
инкапсуляция зашифрованных данных ESP
В случае использования инкапсуляции зашифрованных данных заголовок ESP является последним в ряду опциональных заголовков, "видимых" в пакете. Поскольку основной целью ESP является обеспечение конфиденциальности данных, разные виды информации могут требовать применения существенно различных алгоритмов шифрования. Следовательно, формат ESP может претерпевать значительные изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные поля: SPI, указывающее на контекст безопасности и Sequence Number Field, содержащее последовательный номер пакета. Поле "ESP Authentication Data" (контрольная сумма), не является обязательным в заголовке ESP. Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.
Рис.4. Формат заголовка ESP
Различают два режима применения ESP и AH (а также их комбинации) - транспортный и туннельный:
Транспортный режим используется для шифрования поля данных IP пакета, содержащего протоколы транспортного уровня (TCP, UDP, ICMP), которое, в свою очередь, содержит информацию прикладных служб. Примером применения транспортного режима является передача электронной почты. Все промежуточные узлы на маршруте пакета от отправителя к получателю используют только открытую информацию сетевого уровня и, возможно, некоторые опциональные заголовки пакета (в IPv6). Недостатком транспортного режима является отсутствие механизмов скрытия конкретных отправителя и получателя пакета, а также возможность проведения анализа трафика. Результатом такого анализа может стать информация об объемах и направлениях передачи информации, области интересов абонентов, расположение руководителей.
Туннельный режим предполагает шифрование всего пакета, включая заголовок сетевого уровня. Туннельный режим применяется в случае необходимости скрытия информационного обмена организации с внешним миром. При этом, адресные поля заголовка сетевого уровня пакета, использующего туннельный режим, заполняются межсетевым экраном организации и не содержат информации о конкретном отправителе пакета. При передаче информации из внешнего мира в локальную сеть организации в качестве адреса назначения используется сетевой адрес межсетевого экрана. После расшифровки межсетевым экраном начального заголовка сетевого уровня пакет направляется получателю.
Security Associations
Security Association (SA) - это соединение, которое предоставляет службы обеспечения безопасности трафика, который передается через него. Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.
политика безопасности
Политика безопасности хранится в SPD (База данных политики безопасности). SPD может указать для пакета данных одно из трех действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA.
SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.
протокол ISAKMP/Oakley
Протокол ISAKMP определяет общую структуру протоколов, которые используются для установления SA и для выполнения других функций управления ключами. ISAKMP поддерживает несколько Областей Интерпретации (DOI), одной из которых является IPSec-DOI. ISAKMP не определяет законченный протокол, а предоставляет "строительные блоки" для различных DOI и протоколов обмена ключами.
Протокол Oakley - это протокол определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает идеальную прямую безопасность (Perfect Forward Secrecy, PFS). Наличие PFS означает невозможность расшифровки всего траффика при компрометации любого ключа в системе.
протокол IKE ipad = байт 0x36, повторенный B раз; Для вычисления HMAC от данных "text" необходимо выполнить следующую операцию: H(K XOR opad, H(K XOR ipad, text)) Из описания следует, что IKE использует для аутентификации сторон HASH величины. Отметим, что под HASH в данном случае подразумевается исключительно название Payload в ISAKMP, и это название не имеет ничего общего со своим содержимым. атаки на AH, ESP и IKE Как известно, это атака, от которой не существует полной защиты. Тем не менее, быстрая отбраковка плохих пакетов и отсутствие какой-либо внешней реакции на них (согласно RFC) позволяют более-менее хорошо справляться с этой атакой. В принципе, большинству (если не всем) известным сетевым атакам (sniffing, spoofing, hijacking и т.п.) AH и ESP при правильном их применении успешно противостоят. С IKE несколько сложнее. Протокол очень сложный, тяжел для анализа. Кроме того, в силу опечаток (в формуле вычисления HASH_R) при его написании и не совсем удачных решений (тот же HASH_R и HASH_I) он содержит несколько потенциальных "дыр" (в частности, в первой фазе не все Payload в сообщении аутентифицируются), впрочем, они не очень серьезные и ведут, максимум, к отказу в установлении соединения.От атак типа replay, spoofing, sniffing, hijacking IKE более-менее успешно защищается. С криптографией несколько сложнее, - она не вынесена, как в AH и ESP, отдельно, а реализована в самом протоколе. Тем не менее, при использовании стойких алгоритмов и примитивов (PRF), проблем быть не должно. В какой-то степени можно рассматривать как слабость IPsec то, что в качестве единственного обязательного к реализации криптоалгоритма в нынешних спецификациях указывается DES (это справедливо и для ESP, и для IKE), 56 бит ключа которого уже не считаются достаточными. Тем не менее, это чисто формальная слабость - сами спецификации являются алгоритмо-независимыми, и практически все известные вендоры давно реализовали 3DES (а некоторые уже и AES).Таким образом, при правильной реализации, наиболее "опасной" атакой остается Denial-Of-Service. оценка протокола IPSec В конце шестидесятых годов американское агентство перспективных исследований в обороне DARPA приняло решение о создании
экспериментальной сети под названием ARPANet. В семидесятых годах ARPANet стала считаться действующей сетью США, и через эту
сеть можно было получить доступ к ведущим университетским и научным центрам США. В начале восьмидесятых годов началась стандартизация
языков программирования, а затем и протоколов взаимодействия сетей. Результатом этой работы стала разработка семиуровневой
модели сетевого взаимодействия ISO/OSI и семейства протоколов TCP/IP, которое стало основой для построения как локальных,
так и глобальных сетей. Базовые механизмы информационного обмена в сетях TCP/IP были в целом сформированы в начале восьмидесятых годов, и были
направлены прежде всего на обеспечение доставки пакетов данных между различными операционными системами с использованием разнородных
каналов связи. Несмотря на то, что идея создания сети ARPANet (впоследствии превратившейся в современный Интернет) принадлежала
правительственной оборонной организации, фактически сеть зародилась в исследовательском мире, и наследовала традиции открытости
академического сообщества. Ещё до коммерциализации Интернета (которая произошла в середине девяностых годов) многие авторитетные
исследователи отмечали проблемы, связанные с безопасностью стека протоколов TCP/IP. Основные концепции протоколов TCP/IP не
полностью удовлетворяют (а в ряде случаев и противоречат) современным представлениям о компьютерной безопасности. До недавнего времени сеть Интернет использовалась в основном для обработки информации по относительно простым протоколам:
электронная почта, передача файлов, удалённый доступ. Сегодня, благодаря широкому распространению технологий WWW, всё активнее
применяются средства распределённой обработки мультимедийной информации. Одновременно с этим растёт объём данных, обрабатываемых
в средах клиент/сервер и предназначенных для одновременного коллективного доступа большого числа абонентов. Разработано несколько
протоколов прикладного уровня, обеспечивающих информационную безопасность таких приложений, как электронная почта (PEM, PGP
и т.п.), WWW (Secure HTTP, SSL и т.п.), сетевое управление (SNMPv2 и т.п.). Однако наличие средств обеспечения безопасности
в базовых протоколах семейства TCP/IP позволит осуществлять информационный обмен между широким спектром различных приложений
и сервисных служб. В 1994 году Совет по архитектуре Интернет (IAB) выпустил отчет "Безопасность архитектуры Интернет". В этом документе
описывались основные области применения дополнительных средств безопасности в сети Интернет, а именно защита от несанкционированного
мониторинга, подмены пакетов и управления потоками данных. В числе первоочередных и наиболее важных защитных мер указывалась
необходимость разработки концепции и основных механизмов обеспечения целостности и конфиденциальности потоков данных. Поскольку
изменение базовых протоколов семейства TCP/IP вызвало бы полную перестройку сети Интернет, была поставлена задача обеспечения
безопасности информационного обмена в открытых телекоммуникационных сетях на базе существующих протоколов. Таким образом,
начала создаваться спецификация Secure IP, дополнительная по отношению к протоколам IPv4 и IPv6. IP Security — это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке
IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC. Спецификация IP Security (известная сегодня как IPsec) разрабатывается Рабочей
группой IP Security Protocol IETF . Первоначально IPsec включал в себя 3 алгоритмо-независимые базовые спецификации, опубликованные
в качестве RFC-документов "Архитектура безопасности IP", "Аутентифицирующий заголовок (AH)", "Инкапсуляция
зашифрованных данных (ESP)" (RFC1825, 1826 и 1827). Необходимо заметить, что в ноябре 1998 года Рабочая группа IP Security
Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов, это RFC2401
— RFC2412. Отметим, что RFC1825-27 на протяжении уже нескольких лет считаются устаревшими и реально не используются. Кроме
этого, существуют несколько алгоритмо-зависимых спецификаций, использующих протоколы MD5, SHA, DES. Рис. 1 – Архитектура IPSec.
Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы
входит разработка Internet Key Management Protocol (IKMP), протокола управления ключами прикладного уровня, не зависящего
от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием
спецификации Internet Security Association and Key Management Protocol (ISAKMP) и протокола Oakley Key Determination Protocol.
Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет
устанавливать сессионные ключи на компьютеры сети Интернет. Ранее рассматривались также возможности использования механизмов
управления ключами протокола SKIP, однако сейчас такие возможности реально практически нигде не используются. Создаваемые
стандарты управления ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым
в системе Kerberos . Протоколами ключевого управления для IPSec на основе Kerberos сейчас занимается
относительно новая рабочая группа KINK (Kerberized Internet Negotiation of Keys). Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации
и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного
обмена т.н. "контекста безопасности" – применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией
и их параметров. Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов
и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом
согласования контекста безопасности является установление индекса параметров безопасности (SPI), представляющего собой указатель
на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности. По сути, IPSec, который станет составной частью IPv6, работает на третьем уровне, т. е. на сетевом уровне. В результате
передаваемые IP-пакеты будут защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure
Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели
OSI, IPSec призван обеспечить низкоуровневую защиту. К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов.
Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования,
в том числе Data Encryption Standard (DES) и Message Digest 5 (MD5). Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты,
такие как алгоритмы аутентификации и ключи. IPSec поддерживает два типа схем управления ключами, с помощью которых участники
могут согласовать параметры сеанса. Эта двойная поддержка в свое время вызвала определенные трения в IETF Working Group. С текущей версией IP, IPv4, могут быть использованы или Internet Secure Association Key Management Protocol (ISAKMP), или
Simple Key Management for Internet Protocol. С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как
IKE, хотя не исключается возможность использования SKIP. Однако, следует иметь в виду, что SKIP уже давно не рассматривается
как кандидат управления ключами, и был исключён из списка возможных кандидатов ещё в 1997 г. Аутентифицирующий заголовок (AH) является обычным опциональным заголовком и, как правило, располагается между основным
заголовком пакета IP и полем данных. Наличие AH никак не влияет на процесс передачи информации транспортного и более высокого
уровней. Основным и единственным назначением AH является обеспечение защиты от атак, связанных с несанкционированным изменением
содержимого пакета, и в том числе от подмены исходного адреса сетевого уровня. Протоколы более высокого уровня должны быть
модифицированы в целях осуществления проверки аутентичности полученных данных. Формат AH достаточно прост и состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов.
Названия полей достаточно ясно отражают их содержимое: Next Header указывает на следующий заголовок, Payload Len представляет
длину пакета, SPI является указателем на контекст безопасности и Sequence Number Field содержит последовательный номер пакета. Последовательный номер пакета был введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого
поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации.
Поскольку сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном
номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные
номера (обычно это число равно 64). В отличие от алгоритмов вычисления контрольной суммы, применяемых в протоколах передачи информации по коммутируемым линиям
связи или по каналам локальных сетей и ориентированных на исправление случайных ошибок среды передачи, механизмы обеспечения
целостности данных в открытых телекоммуникационных сетях должны иметь средства защиты от внесения целенаправленных изменений.
Одним из таких механизмов является специальное применение алгоритма MD5: в процессе формирования AH последовательно вычисляется
хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного
результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по
крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям. В случае использования инкапсуляции зашифрованных данных заголовок ESP является последним в ряду опциональных заголовков,
"видимых" в пакете. Поскольку основной целью ESP является обеспечение конфиденциальности данных, разные виды информации
могут требовать применения существенно различных алгоритмов шифрования. Следовательно, формат ESP может претерпевать значительные
изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные
поля: SPI, указывающее на контекст безопасности и Sequence Number Field, содержащее последовательный номер пакета. Поле "ESP
Authentication Data" (контрольная сумма), не является обязательным в заголовке ESP. Получатель пакета ESP расшифровывает
ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного
уровня. Различают два режима применения ESP и AH (а также их комбинации) — транспортный и туннельный. Транспортный режим используется для шифрования поля данных IP пакета, содержащего протоколы транспортного уровня (TCP,
UDP, ICMP), которое, в свою очередь, содержит информацию прикладных служб. Примером применения транспортного режима является
передача электронной почты. Все промежуточные узлы на маршруте пакета от отправителя к получателю используют только открытую
информацию сетевого уровня и, возможно, некоторые опциональные заголовки пакета (в IPv6). Недостатком транспортного режима
является отсутствие механизмов скрытия конкретных отправителя и получателя пакета, а также возможность проведения анализа
трафика. Результатом такого анализа может стать информация об объемах и направлениях передачи информации, области интересов
абонентов, расположение руководителей. Туннельный режим предполагает шифрование всего пакета, включая заголовок сетевого уровня. Туннельный режим применяется
в случае необходимости скрытия информационного обмена организации с внешним миром. При этом, адресные поля заголовка сетевого
уровня пакета, использующего туннельный режим, заполняются межсетевым экраном организации и не содержат информации о конкретном
отправителе пакета. При передаче информации из внешнего мира в локальную сеть организации в качестве адреса назначения используется
сетевой адрес межсетевого экрана. После расшифровки межсетевым экраном начального заголовка сетевого уровня пакет направляется
получателю. Security Association (SA) — это соединение, которое предоставляет службы обеспечения безопасности трафика, который передаётся
через него. Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется
только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом,
если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA. Политика безопасности хранится в SPD (База данных политики безопасности). SPD может указать для пакета данных одно из трёх
действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD
также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами
должен быть создан новый SA. SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета.
Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее
действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные
SA будут использоваться для каждого приложения, или даже для каждого TCP соединения. Протокол ISAKMP определяет общую структуру протоколов, которые используются для установления SA и для выполнения других
функций управления ключами. ISAKMP поддерживает несколько Областей Интерпретации (DOI), одной из которых является IPSec-DOI.
ISAKMP не определяет законченный протокол, а предоставляет "строительные блоки" для различных DOI и протоколов обмена
ключами. Протокол Oakley — это протокол определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает
идеальную прямую безопасность (Perfect Forward Secrecy — PFS). Наличие PFS означает невозможность расшифровки всего траффика
при компрометации любого ключа в системе. IKE — протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным. IKE находится на вершине
ISAKMP и выполняет, собственно, установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций
для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF). Хэш-функция — это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти
два разных сообщения m 1
и m 2
, таких, что H(m 1)
=H(m 2)
,
где H
— хэш функция. Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции
HMAC (HMAC — механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая
хэш функция (обозначим её как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с
помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков
в байтах, а длину блоков, полученных в результате хэширования — как L (L Ipad = байт 0x36, повторённый B раз; Для вычисления HMAC от данных "text" необходимо выполнить следующую операцию: H(K XOR opad, H(K XOR ipad, text)) Из описания следует, что IKE использует для аутентификации сторон HASH величины. Отметим, что под HASH в данном случае подразумевается
исключительно название Payload в ISAKMP, и это название не имеет ничего общего со своим содержимым. Все виды атак на компоненты IPSec можно разделить на следующие группы: атаки, эксплуатирующие конечность ресурсов системы
(типичный пример — атака "Отказ в обслуживании", Denial-of-service или DOS-атака), атаки, использующие особенности
и ошибки конкретной реализации IPSec и, наконец, атаки, основанные на слабостях самих протоколов. AH и ESP. Чисто криптографические
атаки можно не рассматривать — оба протокола определяют понятие "трансформ", куда скрывают всю криптографию. Если
используемый криптоалгоритм стоек, а определенный с ним трансформ не вносит дополнительных слабостей (это не всегда так, поэтому
правильнее рассматривать стойкость всей системы — Протокол-Трансформ-Алгоритм), то с этой стороны все нормально. Что остается?
Replay Attack — нивелируется за счет использования Sequence Number (в одном единственном случае это не работает — при использовании
ESP без аутентификации и без AH). Далее, порядок выполнения действий (сначала шифрация, потом аутентификация) гарантирует
быструю отбраковку "плохих" пакетов (более того, согласно последним исследованиям в мире криптографии, именно такой
порядок действий наиболее безопасен, обратный порядок в некоторых, правда очень частных случаях, может привести к потенциальным
дырам в безопасности; к счастью, ни SSL, ни IKE, ни другие распространенные протоколы с порядком действий "сначала аутентифицировать,
потом зашифровать", к этим частным случаям не относятся, и, стало быть, этих дыр не имеют). Остается Denial-Of-Service
атака. Как известно, это атака, от которой не существует полной защиты. Тем не менее, быстрая отбраковка плохих пакетов и
отсутствие какой-либо внешней реакции на них (согласно RFC) позволяют более-менее хорошо справляться с этой атакой. В принципе,
большинству (если не всем) известным сетевым атакам (sniffing, spoofing, hijacking и т.п.) AH и ESP при правильном их применении
успешно противостоят. С IKE несколько сложнее. Протокол очень сложный, тяжел для анализа. Кроме того, в силу опечаток (в формуле
вычисления HASH_R) при его написании и не совсем удачных решений (тот же HASH_R и HASH_I) он содержит несколько потенциальных
"дыр" (в частности, в первой фазе не все Payload в сообщении аутентифицируются), впрочем, они не очень серьезные и
ведут, максимум, к отказу в установлении соединения.От атак типа replay, spoofing, sniffing, hijacking IKE более-менее успешно
защищается. С криптографией несколько сложнее, — она не вынесена, как в AH и ESP, отдельно, а реализована в самом протоколе.
Тем не менее, при использовании стойких алгоритмов и примитивов (PRF), проблем быть не должно. В какой-то степени можно рассматривать
как слабость IPsec то, что в качестве единственного обязательного к реализации криптоалгоритма в нынешних спецификациях указывается
DES (это справедливо и для ESP, и для IKE), 56 бит ключа которого уже не считаются достаточными. Тем не менее, это чисто формальная
слабость — сами спецификации являются алгоритмо-независимыми, и практически все известные вендоры давно реализовали 3DES (а
некоторые уже и AES).Таким образом, при правильной реализации, наиболее "опасной" атакой остается Denial-Of-Service. Протокол IPSec получил неоднозначную оценку со стороны специалистов. С одной стороны, отмечается, что протокол IPSec является
лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft
PPTP). По мнению другой стороны, присутствует чрезмерная сложность и избыточность протокола. Так, Niels Ferguson и Bruce Schneier
в своей работе "A Cryptographic Evaluation of IPsec" отмечают,
что они обнаружили серьёзные проблемы безопасности практически во всех главных компонентах IPsec. Эти авторы также отмечают,
что набор протоколов требует серьёзной доработки для того, чтобы он обеспечивал хороший уровень безопасности. В работе приведено
описание ряда атак, использующих как слабости общей схемы обработки данных, так и слабости криптографических алгоритмов. В этой статье мы рассмотрели некоторые основные моменты, касающиеся протокола сетевой безопасности IPsec. Не лишним будет
отметить, что протокол IPsec доминирует в большинстве реализаций виртуальных частных сетей. В настоящее время на рынке представлены
как программные реализации (например, протокол реализован в операционной системе Windows2000 компании Microsoft),
так и программно-аппаратные реализации IPsec — это решения
Cisco , Nokia . Несмотря на большое число различных решений, все они
довольно хорошо совместимы друг с другом. В заключение статьи приводится таблица, в которой производится сравнение IPSec и
широко распространённого сейчас SSL. Вконтакте Одноклассники (The Internet Key Exchange (IKE)) - Обмен ключами.
Протоколы IPsec, в отличие от других хорошо известных протоколов SSL и TLS , работают на сетевом уровне (уровень 3 модели OSI). Это делает IPsec более гибким, так что он может использоваться для защиты любых протоколов, базирующихся на TCP и UDP . IPsec может использоваться для обеспечения безопасности между двумя IP-узлами , между двумя шлюзами безопасности или между IP-узлом и шлюзом безопасности. Протокол является "надстройкой" над IP-протоколом, и обрабатывает сформированные IP-пакеты описанным ниже способом. IPsec может обеспечивать целостность и/или конфиденциальность данных передаваемых по сети. IPsec использует следующие протоколы для выполнения различных функций: Концепция "Защищенного виртуального соединения" (SA, "Security Association") является фундаментальной в архитектуре IPsec. SA представляет собой симплексное соединение , которое формируется для транспортирования по нему соответствующего трафика. При реализации услуг безопасности формируется SA на основе использования протоколов AH или ESP (либо обоих одновременно). SA определен в соответствии с концепцией межтерминального соединения (point-to-point) и может функционировать в двух режимах: транспортный режим (РТР) и режим тунелирования (РТУ). Транспортный режим реализуется при SA между двумя IP-узлами. В режиме туннелирования SA формирует IP-туннель . Все SA хранятся в базе данных SADB (Security Associations Database) IPsec-модуля. Каждое SA имеет уникальный маркер, состоящий из трех элементов: IPsec-модуль, имея эти три параметра, может отыскать в SADB запись о конкретном SA. В список компонентов SA входят: Так как защищенные виртуальные соединения(SA) являются симплексными , то для организации дуплексного канала, как минимум, нужны два SA. Помимо этого, каждый протокол (ESP/AH) должен иметь свою собственную SA для каждого направления, то есть, связка AH+ESP требует наличия четырех SA. Все эти данные располагаются в SADB. Помимо базы данных SADB, реализации IPsec поддерживают базу данных SPD (Security Policy Database- База данных политик безопасности). Запись в SPD состоит из набора значений полей IP-заголовка и полей заголовка протокола верхнего уровня. Эти поля называются селекторами. Селекторы используются для фильтрации исходящих пакетов, с целью поставить каждый пакет в соответствие с определенным SA. Когда формируется пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся SPD. Находятся соответствующие SA. Затем определяется SA (в случае, если оно имеется) для пакета и сопряженный с ней индекс параметров безопасности(SPI). После чего выполняются операции IPsec(операции протокола AH или ESP). Примеры селекторов, которые содержатся в SPD: Протокол AH используется для аутентификации, то есть для подтверждения того, что мы связываемся именно с тем, с кем предполагаем, и что данные, которые мы получаем, не искажены при передаче. Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает AH-обработку, то он начинает обработку. В зависимости от режима (транспортный или режим туннелирования) он по-разному вставляет AH-заголовок в IP-пакет. В транспортном режиме AH-заголовок располагается после заголовка протокола IP и перед заголовками протоколов верхнего уровня (Обычно, TCP или UDP). В режиме туннелирования весь исходный IP-пакет обрамляется сначала заголовком AH, затем заголовком IP-протокола. Такой заголовок называется внешним, а заголовок исходного IP-пакета- внутренним. После этого передающий IPsec-модуль должен сгенерировать последовательный номер и записать его в поле Sequence Number
. При установлении SA последовательный номер устанавливается в 0, и перед отправкой каждого IPsec-пакета увеличивается на единицу. Кроме того, происходит проверка- не зациклился ли счетчик. Если он достиг своего максимального значения, то он снова устанавливается в 0. Если используется услуга по предотвращению повторной передачи, то при достижении счетчика своего максимального значения, передающий IPsec-модуль переустанавливает SA. Таким образом обеспечивается защита от повторной посылки пакета - приемный IPsec-модуль будет проверять поле Sequence Number
, и игнорировать повторно приходящие пакеты. Далее происходит вычисление контрольной суммы ICV. Надо заметить, что здесь контрольная сумма вычисляется с применением секретного ключа, без которого злоумышленник сможет заново вычислить хэш, но не зная ключа, не сможет сформировать правильную контрольную сумму. Конкретные алгоритмы, использующиеся для вычисления ICV, можно узнать из RFC 4305 . В настоящее время могут применяться, например, алгоритмы HMAC-SHA1-96 или AES-XCBC-MAC-96. Протокол АН вычисляет контрольную сумму(ICV) по следующим полям IPsec-пакета: После получения пакета, содержащего сообщение АН-протокола, приемный IPsec-модуль ищет соответствующее защищенное виртуальное соединение(SA) SADB (Security Associations Database), используя IP-адрес получателя, протокол безопасности (АН) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищенное виртуальное соединение(SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, т.е. на необходимость проверки поля Sequence Number
. Если услуга используется, то поле проверяется. Для этого используется метод скользящего окна. Приемный IPsec-модуль формирует окно с шириной W. Левый край окна соответствует минимальному последовательному номеру(Sequence Number
) N правильно принятого пакета. Пакет с полем Sequence Number
, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем приемный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле "Integrity Check Value". Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным и принимается для дальнейшей IP-обработки. Если проверка дала отрицательный результат, то приемный пакет уничтожается. Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает ESP-обработку, то он начинает обработку. В зависимости от режима(транспортный или режим туннелирования) исходный IP-пакет обрабатывается по-разному. В транспортном режиме передающий IPsec-модуль осуществляет процедуру обрамления(инкапсуляции) протокола верхнего уровня(например, TCP или UDP), используя для этого ESP-заголовок и ESP-концевик, не затрагивая при этом заголовок исходного IP-пакета. В режиме туннелирования IP-пакет обрамляется ESP-заголовком и ESP-концевиком, после чего обрамляется внешним IP-заголовком. Далее производится шифрование- в транспортном режиме шифруется только сообщение протокола выше лежащего уровня (т.е. все, что находилось после IP-заголовка в исходном пакете), в режиме туннелирования- весь исходный IP-пакет. Передающий IPsec-модуль из записи о SA определяет алгоритм шифрования и секретный ключ. Стандарты IPsec разрешают использование алгоритмов шифрования triple-DES, AES и Blowfish. Так как размер открытого текста должен быть кратен определенному числу байт, например, размеру блока для блочных алгоритмов, перед шифрованием производится еще и необходимое дополнение шифруемого сообщения. Защифрованное сообщение помещается в поле Payload Data
. В поле Pad Length
помещается длина дополнения. Затем, как и в AH, вычисляется Sequence Number
. После чего считается контрольная сумма(ICV). Контрольная сумма, в отличие от протокола AH, где при ее вычислении учитываются также и некоторые поля IP-заголовка, в ESP вычисляется только по полям ESP-пакета за вычетом поля ICV. Перед вычислением контрольной суммы оно заполняется нулями. Алгоритм вычисления ICV, как и в протоколе AH, передающий IPsec-модуль узнает из записи об SA, с которым связан обрабатываемый пакет. После получения пакета, содержащего сообщение ESP-протокола, приемный IPsec-модуль ищет соответствующее защищенное виртуальное соединение(SA) в SADB (Security Associations Database), используя IP-адрес получателя, протокол безопасности (ESP) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищенное виртуальное соединение(SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, т.е. на необходимость проверки поля Sequence Number. Если услуга используется, то поле проверяется. Для этого, так же как и в AH, используется метод скользящего окна. Приемный IPsec-модуль формирует окно с шириной W. Левый край окна соответствует минимальному последовательному номеру(Sequence Number) N правильно принятого пакета. Пакет с полем Sequence Number, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем, если используется услуга аутентификации, приемный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле "Integrity Check Value". Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным. Если проверка дала отрицательный результат, то приемный пакет уничтожается. Далее производится расшифрование пакета. Приемный IPsec-модуль узнает из записи об SA, какой алгоритм шифрования используется и секретный ключ. Надо заметить, что проверка контрольной суммы и процедура расшифрования могут проводиться не только последовательно, но и параллельно. В последнем случае процедура проверки контрольной суммы должна закончиться раньше процедуры расшифрования, и если проверка ICV провалилась, процедура расшифрования также должна прекратиться. Это позволяет быстрее выявлять испорченные пакеты, что, в свою очередь, повышает уровень защиты от атак типа "отказ в обслуживании"(DOS-атаки). Далее расшифрованное сообщение в соответствии с полем Next Header
передается для дальнейшей обработки. Протокол IPsec используется, в основном, для организации VPN-туннелей . В этом случае протоколы ESP и AH работают в режиме туннелирования. Кроме того, настраивая политики безопасности определенным образом, протокол можно использовать для создания межсетевого экрана. Смысл межсетевого экрана заключается в том, что он контролирует и фильтрует проходящие через него пакеты в соответствии с заданными правилами. Устанавливается набор правил, и экран просматривает все проходящие через него пакеты. Если передаваемые пакеты попадают под действие этих правил, межсетевой экран обрабатывает их соответствующим образом. Например, он может отклонять определенные пакеты, тем самым прекращая небезопасные соединения. Настроив политику безопасности соответствующим образом, можно, например, запретить интернет-трафик. Для этого достаточно запретить отсылку пакетов, в которые вкладываются сообщения протоколов HTTP и HTTPS . IPsec можно применять и для защиты серверов - для этого отбрасываются все пакеты, кроме пакетов, необходимых для корректного выполнения функций сервера. Например, для Web-сервера можно блокировать весь трафик, за исключением соединений через 80-й порт протокола TCP, или через порт TCP 443 в случаях, когда применяется HTTPS . Chaply
Check Point VPN-1
Cisco Systems VPN Client
CloudVPN
CryptoLink
Gbridge
Hamachi
Jabpunch
Microsoft Forefront Unified Access Gateway
n2n
NetworkManager
OpenVPN
Openswan
pLan OpenVPN Edition (ZeroGC Gaming Client)
rp-pppoe
Social VPN
strongSwan
Tinc
tcpcrypt
Vyatta
Wippien
IPSec
опирается на ряд технологических решений
и методов шифрования, но действие IPSec в
общем можно представить в виде следующих
главных шагов: Шаг
1.
Начало
процесса IPSec
.
Трафик, которому требуется шифрование
в соответствии с политикой защиты
IPSec, согласованной сторонами IPSec, начинает
IКЕ-процесс. Шаг
2.
Первая
фаза IKE
.
IKE-процесс выполняет аутентификацию
сторон IPSec и ведет переговоры о параметрах
ассоциаций защиты IKE, в результате чего
создается защищенный канал для ведения
переговоров о параметрах ассоциаций
защиты IPSec в ходе второй фазы IKE. Шаг
3.
Вторая
фаза IKE
.
IKE-процесс ведет переговоры о параметрах
ассоциации защиты IPSec и устанавливает
соответствующие ассоциации защиты
IPSec для устройств сообщающихся сторон. Шаг
4.
Передача
данных.
Происходит обмен данными между
сообщающимися сторонами IPSec, который
основывается на параметрах IPSec и ключах,
хранимых в базе данных ассоциаций
защиты. Шаг
5.
Завершение
работы туннеля IPSec
.
Ассоциации защиты IPSec завершают свою
работу либо в результате их удаления,
либо по причине превышения предельного
времени их существования. Существует
два режима работы IPSec:
транспортный и туннельный. В
транспортном режиме шифруется только
информативная часть IP-пакета.
Маршрутизация не затрагивается, так
как заголовок IP-пакета
не изменяется. Транспортный режим, как
правило, используется для установления
соединения между хостами. В
туннельном режиме IP-пакет
шифруется целиком. Для того, чтобы его
можно было передать по сети, он помещается
в другой IP-пакет.
Таким образом, получается защищенный
IP-туннель.
Туннельный режим может использоваться
для подключения удаленных компьютеров
к виртуальной частной сети или для
организации безопасной передачи данных
через открытые каналы связи (Internet)
между шлюзами для объединения разных
частей виртуальной частной сети. Согласование
преобразований IPSec
В
ходе работы протокола IKE ведутся
переговоры о преобразованиях IPSec
(алгоритмах защиты IPSec). Преобразования
IPSec и связанные с ними алгоритмы шифрования
являются следующими: Протокол
АН (Authentication Header - заголовок аутентификации).
Протокол зашиты, обеспечивающий
аутентификацию и (в качестве опции)
сервис выявления воспроизведения.
Протокол АН действует как цифровая
подпись и гарантирует, что данные в
пакете IP не будут несанкционированно
изменены. Протокол АН не обеспечивает
сервис шифрования и дешифрования
данных. Данный протокол может
использоваться или самостоятельно,
или совместно с протоколом ESP. Протокол
ESP (Encapsulating Security Payload -- включающий защиту
полезный груз).
Протокол защиты, обеспечивающий
конфиденциальность и защиту данных, а
также (в качестве опции) сервис
аутентификации и выявления воспроизведения.
Поддерживающие IPSec продукты Cisco используют
ESP для шифрования полезного груза
IP-пакетов. Протокол ESP может использоваться
самостоятельно или совместно с АН. Стандарт
DES (Data Encription Standard -- стандарт шифрования
данных).
Алгоритм шифрования и дешифрования
данных пакетов. Алгоритм DES используется
как в рамках IPSec, так и IKE. Для алгоритма
DES используется 56-битовый ключ, что
означает не только более высокое
потребление вычислительных ресурсов,
но и более надежное шифрование. Алгоритм
DES является симметричным алгоритмом
шифрования, для которого требуются
идентичные секретные ключи шифрования
в устройствах каждой из сообщающихся
сторон IPSec. Для создания симметричных
ключей применяется алгоритм Диффи-Хеллмана.
IKE и IPSec используют алгоритм DES для
шифрования сообщений. "Тройной"
DES (3DES).
Вариант DES, основанный на использовании
трех итераций стандартного DES с тремя
разными ключами, что практически
утраивает стойкость DES. Алгоритм 3DES
используется в рамках IPSec для шифрования
и дешифрования потока данных. Данный
алгоритм использует 168-битовый ключ,
что гарантирует высокую надежность
шифрования. IKE и IPSec используют алгоритм
3DES для шифрования сообщений. AES
(advanced encryption standard
).
Протокол AES использует алгоритм
шифрования Rine Dale4, который обеспечивает
существенно более надежное шифрование.
Многие криптографы считают, что AES
вообще невозможно взломать. Сейчас AES
является федеральным стандартом
обработки информации. Он определен как
алгоритм шифрования для использования
правительственными организациями США
для защиты важных, но несекретных
сведений. Проблема, связанная с AES,
состоит в том, что для его реализации
требуется большая вычислительная
мощность по сравнению с аналогичными
протоколами. При
преобразовании IPSec используется также
два стандартных алгоритма хэширования,
обеспечивающих аутентификацию данных. Алгоритм
MD5 (Message Digest 5).
Алгоритм хэширования, применяемый для
аутентификации пакетов данных. В
продуктах Cisco используется вычисляемый
с помощью MD5 код НМАС (Hashed Message Authentication
Code -- хэшированный код аутентичности
сообщения)- вариант кода аутентичности
сообщения, которому обеспечивается
дополнительная защита с помощью
хэширования. Хэширование представляет
собой процесс одностороннего (т.е.
необратимого) шифрования, в результате
которого для поступающего на вход
сообщения произвольной длины получается
вывод фиксированной длины. IKE, АН и ESP
используют MD5 для аутентификации данных. Алгоритм
SHA-1 (Secure Hash Algorithm-1 -- защищенный алгоритм
хэширования 1).
Алгоритм хэширования, используемый
для аутентификации пакетов данных. В
продуктах Cisco применяется вариант кода
НМАС, вычисляемый с помощью SHA-1. IKЕ, АН
и ESP используют SHA-1 для аутентификации
данных. В
рамках протокола IKE симметричные ключи
создаются с помощью алгоритма
Диффи-Хеллмана, использующего DES, 3DES,
MD5 и SHA. Протокол Диффи-Хеллмана является
криптографическим протоколом, основанным
на применении открытых ключей. Он
позволяет двум сторонам согласовать
общий секретный ключ, не имея достаточно
надежного канала связи. Общие секретные
ключи требуются для алгоритмов DES и
НМАС. Алгоритм Диффи-Хеллмана используется
в рамках IKE для создания сеансовых
ключей. Группы Diffie-Hellman (DH) – определяют
«силу» ключа шифрования, который
используется в процедуре обмена ключами.
Чем выше номер группы, тем «сильнее» и
безопаснее ключ. Однако следует учитывать
тот факт, что при увеличении номер группы
DH увеличивается «сила» и уровень
безопасности ключа, однако одновременно
увеличивается нагрузка на центральный
процессор, так как для генерации более
«сильного» ключа необходимо больше
времени и ресурсов. Устройства
WatchGuard поддерживают DH группы 1, 2 и 5: DH
group 1: 768-bit key DH
group 2: 1024-bit key DH
group 5: 1536-bit key Оба
устройства, которые обмениваются данными
через VPN должны использовать одну и ту
же группу DH. Группа DH, которая будет
использоваться устройствами, выбирается
во время IPSec Phase 1 процедуры.
IKE - протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным. IKE находится на вершине ISAKMP и выполняет, собственно, установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).
Хэш-функция - это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что H(m1)=H(m2), где H - хэш функция.
Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC - механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим ее как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования - как L (L
opad = байт 0x5C, повторенный B раз.
Все виды атак на компоненты IPSec можно разделить на следующие группы: атаки, эксплуатирующие конечность ресурсов системы (типичный пример - атака "Отказ в обслуживании", Denial-of-service или DOS-атака), атаки, использующие особенности и ошибки конкретной реализации IPSec и, наконец, атаки, основанные на слабостях самих протоколов AH и ESP. Чисто криптографические атаки можно не рассматривать - оба протокола определяют понятие "трансформ", куда скрывают всю криптографию. Если используемый криптоалгоритм стоек, а определенный с ним трансформ не вносит дополнительных слабостей (это не всегда так, поэтому правильнее рассматривать стойкость всей системы - Протокол-Трансформ-Алгоритм), то с этой стороны все нормально. Что остается? Replay Attack - нивелируется за счет использования Sequence Number (в одном единственном случае это не работает - при использовании ESP без аутентификации и без AH). Далее, порядок выполнения действий (сначала шифрация, потом аутентификация) гарантирует быструю отбраковку "плохих" пакетов (более того, согласно последним исследованиям в мире криптографии, именно такой порядок действий наиболее безопасен, обратный порядок в некоторых, правда очень частных случаях, может привести к потенциальным дырам в безопасности; к счастью, ни SSL, ни IKE, ни другие распространенные протоколы с порядком действий "сначала аутентифицировать, потом зашифровать", к этим частным случаям не относятся, и, стало быть, этих дыр не имеют). Остается Denial-Of-Service атака.
Протокол IPSec получил неоднозначную оценку со стороны специалистов. С одной стороны, отмечается, что протокол IPSec является лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft PPTP). По мнению другой стороны, присутствует чрезмерная сложность и избыточность протокола. Так, Niels Ferguson и Bruce Schneier в своей работе "A Cryptographic Evaluation of IPsec" отмечают, что они обнаружили серьезные проблемы безопасности практически во всех главных компонентах IPsec. Эти авторы также отмечают, что набор протоколов требует серьезной доработки для того, чтобы он обеспечивал хороший уровень безопасности.Краткая историческая справка появления протокола
Архитектура IPSec
Рис. 2 — Модель OSI/ISO.
Заголовок AH
Рис. 3 — Формат заголовка AH.
Заголовок ESP
Рис. 4 — Формат заголовка ESP.
Транспортный режим
Туннельный режим
Security Associations
Политика безопасности
ISAKMP/Oakley
IKE
opad = байт 0x5C, повторённый B раз.Атаки на AH, ESP и IKE.
Оценка протокола
Заключение
Особенности
IPSec
SSL
Аппаратная независимость
Да
Да
Код
Не требуется изменений для приложений. Может потребовать доступ к исходному коду стека TCP/IP.
Требуются изменения в приложениях. Могут потребоваться новые DLL или доступ к исходному коду приложений.
Защита
IP пакет целиком. Включает защиту для протоколов высших уровней.
Только уровень приложений.
Фильтрация пакетов
Основана на аутентифицированных заголовках, адресах отправителя и получателя, и т.п. Простая и дешёвая. Подходит для роутеров.
Основана на содержимом и семантике высокого уровня. Более интеллектуальная и более сложная.
Производительность
Меньшее число переключений контекста и перемещения данных.
Большее число переключений контекста и перемещения данных. Большие блоки данных могут ускорить криптографические операции
и обеспечить лучшее сжатие.
Платформы
Любые системы, включая роутеры
В основном, конечные системы (клиенты/серверы), также firewalls.
Firewall/VPN
Весь трафик защищён.
Защищён только трафик уровня приложений. ICMP, RSVP, QoS и т.п. могут быть незащищены.
Прозрачность
Для пользователей и приложений.
Только для пользователей.
Текущий статус
Появляющийся стандарт.
Широко используется WWW браузерами, также используется некоторыми другими продуктами.
Ссылки
Благодарности
Архитектура IPsec
Security Association
Authentication Header
Authentication Header
format
Next Header
(8 bits)
Тип заголовка протокола, идущего после заголовка AH. По этому полю приемный IP-sec модуль узнает о защищаемом протоколе верхнего уровня. Значения этого поля для разных протоколов можно посмотреть в RFC 1700 .
Payload Len
(8 bits)
Это поле определяет общий размер АН-заголовка в 32-битовых словах, минус 2. Несмотря на это, при использовании IPv6 длина заголовка должна быть кратна 8 байтам.
Reserved
(16 bits)
Зарезервировано. Заполняется нулями.
Security Parameters Index
(32 bits)
Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяет защищенное виртуальное соединение(SA) для данного пакета. Диапазон значений SPI 1...255 зарезервирован IANA.
Sequence Number
(32 bits)
Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может отказаться от услуги по защите от повторной передачи пакетов, оно является обязательным и всегда присутствует в AH-заголовке. Передающий IPsec-модуль всегда использует это поле, но получатель может его и не обрабатывать.
Integrity Check Value
Offsets
Octet 16
0
1
2
3
Octet 16
Bit 10
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
0
0
Next Header
Payload Len
Reserved
4
32
8
64
Sequence Number
C
96
Integrity Check Value (ICV)
…
…
…
Обработка выходных IP-пакетов
Если поле может изменяться в процессе транспортировки, то его значение устанавливается в 0 перед вычислением ICV. Исключения составляют поля, которые могут изменяться, но значение которых можно предугадать при приеме. При вычислении ICV они не заполняются нулями. Примером изменяемого поля может служить поле контрольной суммы, примером изменяемого, но предопределенного может являться IP-адрес получателя. Более подробное описание того, какие поля как учитываются при вычислении ICV, можно найти в стандарте RFC 2402 .
Обработка входных IP-пакетов
Encapsulating Security Payload
format
Security Parameters Index
(32 bits)
Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности(АН-протокол), однозначно определяет защищенное виртуальное соединение(SA) для данного пакета. Диапазон значений SPI 1...255 зарезервирован IANA для последующего использования.
Sequence Number
(32 bits)
Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может и отказаться от услуги по защите от повторной передачи пакетов, оно всегда присутствует в AH-заголовке. Отправитель(передающий IPsec-модуль) должен всегда использовать это поле, но получатель может и не нуждаться в его обработке.
Payload data
(variable)
Это поле содержит данные в соответствии с полем "Next Header". Это поле является обязательным и состоит из целого числа байтов. Если алгоритм, который используется для шифрования этого поля, требует данных для синхронизации криптопроцессов (например, вектор инициализации - "Initialization Vector"), то это поле может содержать эти данные в явном виде.
Padding
(0-255 octets)
Дополнение. Необходимо, например, для алгоритмов, которые требуют, чтобы открытый текст был кратен некоторому числу байтов), например, размеру блока для блочного шифра.
Pad Length
(8 bits)
Размер дополнения(в байтах).
Next Header
(8 bits)
Это поле определяет тип данных, содержащихся в поле "Payload data".
Integrity Check Value
Контрольная сумма. Должна быть кратна 8-байтам для IPv6, и 4-байтам для IPv4.
Offsets
Octet 16
0
1
2
3
Octet 16
Bit 10
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
0
0
Security Parameters Index (SPI)
4
32
Sequence Number
8
64
Payload data
…
…
…
…
…
…
Padding (0-255 octets)
…
…
Pad Length
Next Header
…
…
Integrity Check Value (ICV)
…
…
…
Обработка выходных IPsec-пакетов
Обработка входных IPsec-пакетов
Использование
См. также
Ссылки
Виртуальные частные сети (VPN)
Программное обеспечение
Механизмы
Управляемые поставщиком
Механизмы безопасности в Режимы работы ipSec