4.2. Защищенные каналы передачи информации

Очень широкое распространение за последние годы получили локальные и глобальные компьютерные сети на основе коммуникационной архитектуры TCP/IP. Одна из причин популярности TCP/IP - хорошо разработанная система функций защиты информа-ции, закрепленная рекомендациями серии RFC, которые публикуются международной организацией IETF (Internet Engineering Task Force). В связи с этим они являются основной нормативно-техничес-кой базой реализации информационных систем, предназначенных для целей электронной коммерции.

В сетях, основанных на архитектуре TCP/IP, наибольшее рас-пространение получили два метода реализации защищенных кана-лов передачи информации. Один из них - применение стандартных механизмов и протоколов защиты информации, определяемых ар-хитектурой безопасности IPSec. Это рамочная модель (frame-work), включающая четыре компонента:

протокол АН - Authentication Header;

протокол ESP - Encapsulating Security Payload;

протокол IPcomp -IP payload compression;

рамочную модель IKE - Internet Key Exchange.

Для каждого из них (занимающих свое место среди протоколов коммуникационной архитектуры TCP/IP) описываются форматы, за-головки, специфические криптографические механизмы и режимы их применения. Архитектура IPSec добавляет к IP-пакетам проверку целостности, подлинности (аутентичности), шифрование и защиту от повтора пакетов.

Архитектура IPSec была создана для обеспечения способности к взаимодействию. При корректной реализации она не оказывает никакого влияния на сети и хосты, не поддерживающие ее. Модель не зависит от используемых криптографических алгоритмов и допускает включение новых алгоритмов по мере их появления. Архитектура поддерживается дня коммуникационных протоколов IPv4 и IPv6 (в по-следнем случае она является обязательным компонентом коммуникационной архитектуры). Конкретная реализация того или иного крипто-графического алгоритма для использования протоколами в архитектуре IPSec называется преобразованием (transform). Например, алгоритм DES, используемый протоколом ESP в режиме сцепления блоков, в терминологии IPSec называется преобразованием ESP DES-CBC. Преобразования, пригодные для использования в протоколах, публи-куются в рекомендациях серии RFC, принятых IETF.

Архитектура IPSec базируется на двух главных компонентах: защищенных ассоциациях (Security Associations - SA) и туннелиро- вании.

Защищенная ассоциация - это однонаправленное (симплексное) ло-гическое соединение между двумя системами, поддерживающими IP-

Sec, которое однозначно идентифицируется тремя параметрами < Security Parameter Index, IP destination address, security protocol >, где Security Parameter Index (SPI) - 32-битовая величина, используемая для иден-тификации различных SA с одним и тем же адресом получателя и про-токолом безопасности (SPI переносится в заголовке протокола безо-пасности - АН или ESP; SPI имеет только локальное значение, так как определяется создателем SA; обычно SPI выбирается системой- получателем во время установления SA); IP destination address - IP- адрес системы-получателя, который может быть адресом единичной системы, а также адресом широковещательной или групповой рассыл-ки; однако текущие механизмы управления SA определены только для адресов единичных систем; Security protocol - величина, которая указывает на выбор протокола АН или ESP.

Защищенная ассоциация может быть установлена в одном из двух режимов: транспортном или туннельном, в зависимости от ре-жима протокола в этой ассоциации.

Каждая отдельно взятая SA предоставляет сервисы безопасности для трафика, переносимого ею либо через протокол АН, либо через протокол ESP, но не через оба протокола сразу. Другими словами, для соединения, которое должно быть защищено одновременно протоко-лами АН и ESP, в каждом направлении должны быть определены две ассоциации. В этом случае все множество SA, которые определены для соединения, носит название связки защищенных ассоциаций (SA bundle). Ассоциации, входящие в связку, не обязательно должны за-вершаться в одной и той же конечной точке. Например, мобильный хост мог бы использовать SA с протоколом АН для связи между собою и межсетевым экраном (МЭ) и другую SA с протоколом ESP, которая продолжается до хоста, расположенного позади МЭ.

Реализация IPSec поддерживает две базы данных (БД), связанные с SA.

Security Policy Database (SPD) - база данных политики безопас-ности, которая специфицирует те сервисы безопасности, которые должны предоставляться IP-трафику. Они зависят от таких факторов, как адреса источников и получателей, «внутриполосный» или «внеполосный» характер трафика и т. п. БД содержит упорядоченный список записей о политике, раздельных для «внутриполосного» и «внеполосного» трафика. Эти записи могут специфицировать, что часть трафика должна миновать обработку через механизмы архи-тектуры IPSec, часть должна быть вообще удалена, а остальной трафик должен быть обработан модулем, реализующим функции архи-тектуры IPSec. Записи в этой БД похожи на правила межсетевого экранирования или пакетной фильтрации.

Security Association Database (SAD) - база данных защищенных ассоциаций, которая содержит параметрическую информацию о ка-ждой SA, в том числе алгоритмы и ключи, используемые протоко-лами АН и ESP, последовательные номера ассоциаций, режимы про-токолов и время жизни SA.

Пользовательский интерфейс реализации IPSec обычно либо скрывает эти БД, либо представляет их в более дружественном виде.

Туннелирование, или инкапсуляция, - это обычный метод защиты для сетей с маршрутизацией пакетов. Он заключается в том, что па-кеты, передаваемые в сети, «оборачиваются» в новые пакеты, так как к первоначальному пакету приписывается новый заголовок и, возможно, хвостовик. Исходный пакет целиком становится заполне-нием нового пакета более низкоуровневого протокола (рис. 4.2). Новый IP- заголовок ^Щ^Л'Г^Врк^ ;' > - Заполн єш щ ІР^п лк Исходная (инкапсулированная) дейтаграмма становится заполнением нового IP-пакета

Рис. 4.2. Принцип туннелирования (инкапсуляции) протоколов

Туннелирование часто используется для того, чтобы перенести трафик какого-либо протокола через сеть, которая не поддерживает этот протокол непосредственно. Например, протоколы NetBIOS или IPX могут быть инкапсулированы в IP-пакеты для переноса их через глобальную сеть, построенную в архитектуре ТСРЛР. Туннелирова- ние можно использовать и для целей защиты информации. Так и происходит в архитектуре IPSec: туннелирование применяется для того, чтобы обеспечить сплошную защиту передаваемых пакетов, включая и заголовки инкапсулируемых пакетов. Если пакеты шиф-руются, то злоумышленник не может извлечь оттуда, к примеру, адрес получателя пакетов (в отсутствие туннелирования он это легко смог бы сделать). Таким образом, от постороннего наблюдателя мо-жет быть скрыта внутренняя структура частной сети.

Туннелирование требует промежуточной обработки исходного пакета при маршрутизации. Адрес получателя, указанный во внешнем заголовке, обычно является адресом межсетевого экрана или маршрутизатора, поддерживающего архитектуру IPSec.

Замечательным преимуществом туннелирования IP-пакетов является способность обмениваться пакетами с частными ІР-адресами между двумя внутренними сетями организаций через публичный канал, который требует, чтобы узлы имели уникальные глобальные адреса. Так как инкапсулированный заголовок не обрабатывается маршрутизаторами в сети Интернет, достаточно, чтобы только око-нечные точки туннеля (шлюзы) имели бы глобально присвоенные адреса. Хосты в частных сетях (интранет-сетях) за ними могут иметь частные адреса (например, вида Ю.х.х.х). Так как глобальные ІР- адреса становятся дефицитными, такой метод взаимосвязи сетей приобретает большое значение. Модель туннелирования в архитек-туре безопасности IPSec описана в рекомендации RFC 2003 - «IP Encapsulation within IP».

Далее мы рассмотрим протоколы архитектуры IPSec, более ин-тересные с технической, нежели с алгоритмической точки зрения, так как их криптографическая «начинка» довольно проста.

Итак, первым компонентом архитектуры безопасности IPSec является протокол АН. Он используется для того, чтобы обеспечить целостность и подлинность IP-дейтаграмм. С его помощью также возможна защита и от повтора пакетов. Хотя его использование рас-сматривается как необязательное, сервис защиты от повтора пакетов должен быть реализован в любой системе, совместимой с архитек-турой IPSec. Сервисы не требуют установки соединений, следова-тельно, должны быть обеспечены для каждого пакета в отдельности. Протокол АН используется в двух режимах: транспортном и тун-нельном.

Протокол АН обеспечивает подлинность для возможно большей части IP-дейтаграмм. В транспортном режиме некоторые поля IP- заголовка изменяются при маршрутизации, поэтому их значения не могут быть предсказаны получателем. Эти поля называются пере-менными (mutable) и не защищаются протоколом АН.

поле, указывающее тип сервиса (Type of service - TOS); поле флагов; • поле смещения фрагмента (Fragment offset); поле времени жизни пакета (Time to live - TTL); поле контрольной суммы заголовка (header checksum).

Когда требуется защита этих полей, должно быть использовано туннелирование. Заполнение IP-пакета рассматривается как неизме-няемое и в любом случае защищается методом АН.

Протокол АН идентифицируется номером протокола 51, присво-енным IANA. Заголовок протокола непосредственно предшествует заголовку протокола АН, содержащему эту величину в своих полях.

Обработка методом, предусмотренным протоколом АН, приме-нима только к нефрагментированным IP-пакетам. Однако IP-пакет с заголовком АН может быть фрагментирован промежуточным мар-шрутизатором. В этом случае получатель сначала собирает пакет, а затем применяет к нему обработку в соответствии с методом, пре-дусмотренным АН. Если при начале обработки оказывается, что ІР- пакет предположительно разбит на фрагменты (поле смещения не-нулевое или флаг More fragments установлен в единицу), он удаляет-ся. Это предотвращает атаку методом перекрытия фрагментов (over-lapping fragment attack), которая возможна при некорректном ис-пользовании алгоритма сборки фрагментов и позволяет искажать пакеты и пересылать их через МЭ.

Пакеты, которые не проходят аутентификацию, удаляются и ни-когда не доставляются на верхние уровни. Этот режим значительно уменьшает вероятность успешного проведения атак, приводящих к отказу в обслуживании, цель которых заключается в том, чтобы блокировать связь с хостом или шлюзом, наводняя их «поддельными» пакетами.

Формат АН-заголовка (рис. 4.3) описан в RFC 2402. В него вхо-дят следующие поля:

«Следующий заголовок» - Next header (8 бит); «Длина заполнения пакета» - Payload length (8 бит); Зарезервированное поле (16 бит, установленных в 0); «Индекс параметра безопасности» - Security Parameter Index (SPI) (32 бита);

«Порядковый номер пакета в последовательности» - Sequence number (32 бита);

«Код аутентификации сообщения» - Authentication data (32 бита для IPv4, 64 бита для IPv6). ' .АН- ¦ '

л J Л ГОЛОВОК-./ ЕР-заголовок Заполнение IP-пакет а

^Сиед: заголовок \ Дтата.запрЛнегаи^;'. ¦^ЬаіУез.^ві'фЬвжо;-'- j;.jv'.>': іуі'ійдексі гі{ірпмвт]їгі¦ $ёзЬпас>гостн^^Ріу//йv;} ? ¦; yVi.. ¦ ;'>¦. '¦ ігіорЯДКОЕЬШ'НОМф- Шкёга к-ПОСЛЄД( ІВ'аТельНОСТІІ ; іЛ", u.:: г^ -К о д1. луг енті 1фїік аці иГ t6o бщейія j . 32 бита >- Рис. 4.3. Формат заголовка протокола АН в соответствии с RFC 2402

Заголовок АН в транспортном режиме вставляется в пакет сразу после заголовка IP-пакета (рис. 4.4). Если дейтаграмма уже имеет заголовок IPSec, заголовок АН помещается перед ним. Транспортный режим используется хостами, но не шлюзами. Шлюзам не тре-буется поддерживать транспортный режим. Преимуществом транспортного режима является меньшая вычислительная сложность, не-достатком - отсутствие проверки подлинности изменяемых полей.

ЕР-заголовок

Заполнение ІР-пакета і'*. - ІР-заголовок :., "АІІ- -заголовок- • Заполненне ЕР-пакета -с ->- Дейтаграмма с АН-зпгачовком в транспортом режиме

Обеспечена аутенпгіность (кроме изменяемых псшеп) Рис. 4.4. Заголовок протокола АН в транспортном режиме

Исходная ІР-деґпаграмма

; „ "АІІ- -заголовок- •

ІР-заголовок

Заполнение ЕР-пакета

АН в туннельном реэ/симе использует ранее рассмотренную кон-цепцию туннелирования. При этом конструируется новая 1Р-дей- таграмма, в то время как исходная становится ее заполнением. АН в транспортном режиме применяется к полученной дейтаграмме (рис. 4.5). Туннельный режим используется всякий раз, когда око-нечным узлом защищенной ассоциации является шлюз. Так, между двумя МЭ всегда используется туннельный режим.

Заполнение IP-пакета

ІР- заголовок

Исходная IP-дейтаграмма

заголовок

Заполненне ІР-пакета

Обеспечена аугенттргность (кроме изменяемых полей в новом ЕР-зяголовке)

Рис. 4.5. Заголовок протокола АН

Туннелирован- ная дейтаграмма Дейтаграмма с АН-заголовком в туннельном режиме

Шлюзы часто также поддерживают и транспортный режим. Этот режим разрешен, когда шлюз действует как хост, т. е. в случаях, когда трафик предназначен самому шлюзу. Например, команды SNMP могут быть направлены шлюзу, используя транспортный режим.

В туннельном режиме IP-адреса внешних заголовков не обяза-тельно должны быть теми же самыми, что и адреса внутренних за-головков. Например, два шлюза могут организовать АН-туннель, который используется для того, чтобы гарантировать подлинность

всего трафика между сетями, которые они соединяют. Это типичный случай применения туннельного режима.

Преимуществом туннельного режима является полная защита инкапсулируемых ІР-дейтаграмм и возможность использования ча-стных адресов. Однако этот режим приводит к дополнительной вы-числительной работе узлов сети.

Протокол ESP используется для обеспечения целостности, под-линности и для шифрования ІР-дейтаграмм, а также (факультативно) для защиты от повторной передачи пакетов. Эти сервисы пре-доставляются без установления соединения, поэтому они должны применяться для каждого пакета в отдельности. Множество требуе-мых сервисов выбирается при установлении защищенной ассоциа-ции (SA). Вместе с тем существуют и некоторые ограничения: • проверка целостности пакета и аутентификация используются совместно;

защита от повтора может выбираться только в совокупности с проверкой целостности и аутентификацией; защита от повтора может быть выбрана только получателем па-кетов.

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

Хотя и аутентификация (с проверкой целостности) и шифрова-ние необязательны, всегда выбирается по меньшей мере одна из этих функций, так как в противном случае использование протокола ESP вообще не имеет смысла.

Протокол ESP идентифицируется номером протокола 50, при-своенным IANA. Заголовок протокола (IPv4, IPv6 или расширение) непосредственно предшествует ESP-заголовку, который и содержит эту величину протокола.

Обработка по методу ESP' применима только к нефрагментиро- ванным IP-пакетам. Однако IP-пакет с примененным к нему ESP может быть фрагментирован промежуточными маршрутизаторами. В этом случае получатель сначала собирает пакет, а затем применяет к нему обработку, предусмотренную протоколом ESP. Если 1Р-па-

кет, который предположительно является фрагментированным, по-ступает для обработки на уровень протокола ESP, он удаляется. Это предотвращает атаку методом перекрытия фрагментов пакетов.

Если выбраны и шифрование и аутентификация с проверкой це-лостности, то получатель вначале проверяет аутентичность пакета и, только если этот шаг завершился успешно, производит расшифровку заполнения пакета. Этот порядок позволяет сэкономить вычисли-тельные ресурсы и уменьшить уязвимость системы защиты к атакам, приводящим к отказу в обслуживании.

Формат пакета при применении ESP (рис. 4.6) описан в RFC 2406. Он более сложен, чем при применении АН, так как включает не только заголовок, но также и концевик и код аутентификации пакета. Заполнение пакета инкапсулируется между заголовком и концевиком, что и дало имя этому методу защиты. | ІР- заголовок f/^pp'-i: заголовок. Заполненпе IP-пакета Конце"-..

.Іл/'ВІГК^ І^шфикащиі^1 Индекспараметр д. бе зопа єно сш- (SE1)

ч. ESP-чаго ловок

ПорядковыГьномер^ пакета в последовательности

к

Заполнение пакета (поле переменной длины)

^Дополнение (от;.О до.<255 байт)

ЬЪд'арденП'фжащ-пгсообщеим^!: щтг.

ESP-концевик

Код аутенти-фикации ESP

І'івМІГіГ.і'С'ї

«Индекс параметра безопасности» - SPI - Security Parameter Index (32 бита);

«Порядковый номер пакета в последовательности» - Sequence number (32 бита);

поле заполнения, т. е. данные, полученные от протокола более высокого уровня - Payload data (обязательное, переменной длины); дополнение предыдущего поля до длины, кратной 256 байт, - Padding (от 0 до 255 байт, установленных в 0); • длина предыдущего поля дополнения - Pad length (8 бит); «Следующий заголовок» - Next header (8 бит, обязательное); «Код аутентификации сообщения» - Authentication data (пере-менной длины).

Как и протокол АН, протокол ESP может использоваться в двух режимах: транспортном и туннельном.

ESP в транспортном реэ/симе. В этом режиме ESP-заголовок следует сразу после IP-заголовка, как показано на рис. 4.7. Если дей-таграмма уже имеет IPSec-заголовок, то ESP-заголовок должен следовать перед первым из них. Концевик протокола ESP и необяза-тельный код аутентификации добавляются к заполнению.

реалше

Рис. 4.7. Заголовок протокола ESP в транспортном режиме

Протокол ESP в транспортном режиме не обеспечивает ни ау-тентификацию, ни шифрование для IP-заголовка. Это недостаток, так как «ложные» пакеты все же моїут быть доставлены для обра-ботки протоколом ESP. Преимущество транспортного режима - низкие вычислительные затраты. Как и в случае АН, протокол ESP

в транспортном режиме используется хостами, но не шлюзами. Шлюзам вообще не требуется поддерживать транспортный режим.