4. Кр//mnоzрафuчеСJ<uепротоколы в элекmРОJllIO'U KOM\feplIUII u в доку.ме/Jтообороmе 219 этого уровня применяется концепция транзакций, или дел (deal). Это последовательность шагов, цель которой - осуществить целостный бизнес-процесс, поддерживая взаимосвязь между отдельными его этапами по мере их выполнения. Ход выполнения транзакции запи сывается всеми участвующими в ней сторонами, причем запись включает получаемую и отправляемую информацию, а также общую информацию о процессе: согласованные атрибуты защиты, иденти фикаторы участников, логические связи между этапами транзакции и др. Все эти сведения являются основой для обработки исключи тельных ситуаций и разрешения споров и конфликтов, возникающих между участниками коммерческих отношений.
Примерами процессов деловой деятельности, для которых обес печение безопасности информации требует целостного их рассмот рения, являются: электронные аукционы, электронные выборы (го лосования), электронные биржи, электронные лотереи и т. П. про цессы. Для всех них требуются специальные криптографические протоколы. Очень большую роль в обеспечении безопасности биз
нес-процессов играют также двусторонние и многосторонние схемы
цифровой подписи со специальными свойствами. Примером может являться оформление прав на недвижимое имущество, требующее, как известно, очень большого количества решений и согласований, а также оформление или регистрация каких-либо иных прав или обязанностей субъектов электронного рынка.
Для решения всех этих довольно непростых задач необходима разработка архитектуры информационных систем для электронной коммерции. Она будет являться базисом реализации целей, которые ставит электронная коммерция и электронный обмен данными, и сможет в конечном итоге обеспечить многостороннюю безопас
ность участников коммерческих и государственно-правовых отно шений.
Одна из таких архитектур, наиболее развитая, - архитектура
SEМPER (Secure Electronic Marketplace for Ешоре), разработанная
в рамках общеевропейского проекта единого электронного рынка.
4.1.2. Пример: архитектура SEMPER
Спецификация SEМPER вводит модельное представление ИН формационных систем для поддержки электронной коммерции,
в которые введены в том числе и функции обеспечения многосто-
220 ЗаnеЧJII/1<овС. В. Криптографическиепротоколы и их применение
ронней безопасности. Она позволяет достичь следующих основных целей:
реализовать множество сценариев бизнес-процессов; определить открытую платформу реализации функций безопас
ности;
гарантировать безопасное управление пользователями своей ИН формацией.
Архитектура SEMPER - пятиуровневая (рис. 4.1). Самый верх ний уровень составляют бизнес-приложения - прикладные про граммы пользователей, выполняющие функции, специфические для электронной коммерции, которые прибегают к услугам нижележа щих уровней архитекгуры.
Бизнес
Бизнес
Бизнес
нрнложенпя
нрнложення
нрнпоженяя
'J.IЮ&fНЬ <убъrlШIO(; делосой деятельности (BI1S;lu"s'S-Itеш Lfl.,J'cr)
Сервисы ноддержкн (SUPIJortillg Sen'it'l's)
Рис. 4.1. Архитектура SEMPER
Коммерческий уровень предоставляетсервисы защиты бизнес приложениям и обеспечивает ориентацию бизнес-процессов,запи сывая статус и текущее состояние бизнес-процессов, включая от крытие новых «дел», доступ к ним и отображениеотдельныхшагов бизнес-процесса,навигациюпользователейвнутри отдельных«дел» и между «делами», экспорт «дел» и т. п. Требования по безопасно сти «дел» отображаются посредством введения атрибутов защиты, относящихсялибо к отдельнымшагам бизнес-процесса(как, напри мер, конфиденциальность),либо ко всему «делу» в целом (напри мер, анонимность). Коммерческий уровень опирается на следую щий - уровень передачи и обмена информацией, который реализует функции, связанные с односторонней передачей данных и обменом данными, включая и необходимые функции по защите этих процес сов. Этот уровень, в свою очередь, опирается на уровень субъектов
4. КрllmnографU'lеекuепротоколы в ;)лектРОll1lOй КОМ.мерЦIIи 11в докумеumооБОРОl1lе 221 деловой деятельности, который управляет передачей сообщений со образно с природой передаваемых и принимаемых данных: обычные данные, электронные документы, «электронные деньги». Этот уро
вень имеет значение только для тех протоколов, в которых сущест
венна природа пересылаемой информации. Сервисы поддержки включают доверенный пользовательский интерфейс, различные вспомогательные сервисы и инфраструктуру для криптографической защиты и обеспечения безопасности каналов связи, локального уче та и архивации данных пользователей.
Функции безопасности, предусмотренные моделью SEMPER, таким образом, оказываются структурированы по трем уровням: коммерческому,передачи и обмена информацией,уровню субъектов деловой деятельности. Необходимым условием применения функ ций защиты в архитектуре SEMPER является наличие соответст вующего правового обеспечения.
4.2. Защищенные каналы передачи информации
Для реализации различных сервисов защиты информации в се тях, построенных на базе коммуникационной архитектуры ТСP/lP , используется ряд типовых механизмов и протоколов защиты. Реше ние, соответствующее практическим потребностям, обычно может быть получено как определенная их комбинация. Среди всех меха низмов защиты, применяемых для целей электронной коммерции и электронного документооборота, важнейшее место занимают сред ства образования защищенных каналов передачи информации. Здесь
мы рассмотрим стандартные протоколы, предназначенные для ре шения этой задачи.
Очень широкое распространение за последние годы получили локальные и глобальные компьютерные сети на основе коммуника ционной архитектуры TCP/IP. Одна из причин популярности TCPIIP - хорошо разработанная система функций защиты информа ции, закрепленная рекомендациями серии RFC, которые публикуют ся международной организацией IETF (Intemet Engineering Task Force). В связи с этим они являются основной нормативно-техничес кой базой реализации информационных систем, предназначенных'
для целей электронной коммерции.
222 Залечииков С. В. Криптографическиепротоколы иих примененив
в сетях) основанных на архитектуре TCP/IP, наибольшее рас
пространение получили два метода реализации защищенных кана лов передачи информации. Один из них - применение стандартных механизмов и протоколов защиты информации, определяемых ар хитектурой безопасности IPSec. Это рамочная модель (frame- \',Tork) включающая четыре компонента:
1)протокол АН - Authentication Header;
2)протокол ESP - Encapsulating Security Payload;
3)протокол IPcomp -IP payload compression;
4)рамочную модель lКE- Intemet Кеу Exchange.
Для каждого из них (занимающих СБое место среди протоколов коммуникационной архитектуры ТСРЛР) описываются форматы, за головки, специфические криптографические механизмы и режимы их применения. Архитектура IPSec добавляет к IР-пакетам проверку целостности, подлинности (аутентичности), шифрование и защиту от повтора пакетов. Она используется для обеспечения безопасности соединений между оконечными пользователями и для создания за щищенных туннелей между шлюзами.
Архитектура IPSec
была создана для обеспечения способности
к взаимодействию. При
корректной реализации она не оказывает
никакого влияния на сети и хосты, не поддерживающие ее. Модель не зависит от используемых криптографических алгоритмов и допуска ет включение новых алгоритмов по мере их появления. Архитектура поддерживается для коммуникационных протоколов IPv4 и IPvб (В по следнем случае она является обязательным компонентом коммуника ционной архитектуры). Конкретная реализация того или иного крипто графического алгоритма для использования протоколами в архитектуре IPSec называется преобразованием (tral1sfo17n). Например, алгоритм
DES, используемый протоколом
БSР в режиме сцепления блоков)
в терминологии IPSec называется
преобразованием ESP DES-CBC.
Преобразования, пригодные для использования в протоколах, публи куются в рекомендациях серии RFC, принятых IETF.
Архитектура IPSec базируется на двух главных компонентах: защищенных ассоциациях (Security Associations - SA) и туннелиро
вании.
Защищенная ассоциация - это однонаправленное (симплексное) ло
гическое соединение между двумя системами, поддерживающими IP-
4. Криптографические IIРО1110КОДЫ вэле/(mРОJlllOй ко.\LШ:РЦИII 11в доку.ltеumообороmе 223 Sec, которое однозначно идентифицируется тремя параметрами < Secu-
rity Parameter Index, IP destination address, security protocol >, где Security
Parameter Index (SPI) - 32-битовая величина, используемая для иден тификации различных SA с одним И тем же адресом получателя и про токолом безопасности (SPI переносится в заголовке протокола безо пасности - АН или БSР; SPI имеет только локальное значение, так как определяется создателем SA; обычно SPI выбирается системой получателем во время установления SA); IP destination address - JP- адрес системы-получателя, который может быть адресом единичной системы, а также адресом широковещательной или групповой рассыл КИ; однако текущие механизмы управления SA определены только для адресов единичных систем; Security pгotocot - величина, которая указы вает на выбор протокола АН или ESP.
Защищенная ассоциация может быть установлена в одном из
двух режимов: транспоргном или туннельном, в зависимости от ре жима протокола в этой ассоциации. Напомним, что SA является симплексным соединением, следовательно, для двунаправленной связи между двумя системами, поддерживающнмиIPSec, должны быть определены две SA, по однойв каждомнаправлении.
Каждая отдельно взятая SA предоставляет сервисы безопасности для трафика, переносимого ею либо через протокол АН, либо через протокол БSР, но не через оба протокола сразу. Другими словами, для соединения, которое должно быть защищено одновременно протоко лами АН и БSР, в каждом направлении должны быть определены две ассоциации. Б этом случае все множество SA, которыеопределеныдля соединения, носит название связки защищенных ассоциаций (SA bundle). Ассоциации) входящие в связку, не обязательно должны за вершаться в одной и той же конечной точке. Например, мобильный хост мог бы использовать SA с протоколом АН для связи между собою и межсетевым экраном (МЭ) и другую SA с протоколом ESP, которая продолжается до хоста, расположенного позади МЭ.
Реализация IPSec поддерживаетдве базы данных (БД), связан ные с SA.
Security Ройсу Database (SPD) - база данных политики безопас ности, которая специфицирует те сервисы безопасности, которые должны предоставляться IР-трафику. Они зависят от таких факто
ров, как адреса источников и получателей, «внутриполосный» или
224 Запечников С. В. Криптографическиепротоколы 11 их применение
«внеполосный» характер трафика и т. п. БД содержит упорядочен ный список записей о политике, раздельных для «внутриполосного» и «внеполосного» трафика. Эти записи МОГУТ специфицировать, что часть трафика должна миновать обработку через механизмы архи тектуры IPSec, часть должна быть вообще удалена, а остальной тра фик должен быть обработан модулем, реализующим функции архи тектуры IPSec. Записи в этой БД похожи на правила межсетевого экранирования или пакетной фильтрации.
SеСllгitу Аязосииюп Database (SAD) - база данных защищенных ассоциаций, которая содержит параметрическую информацию о ка ждой SA, в том числе алгоритмы и ключи, используемые протоко лами АН и ESP, последовательные номера ассоциаций, режимы про токолов и время жизни SA. ДЛЯ «внеполосной»обработки записи SPD указывают на записи в SAD, т. е. SPD определяет, какие SA должны быть использованы для данного пакета. Для «внутриполос ной» обработки SAD служит средством определенияспособа обра ботки пакета.
Пользовательский интерфейс реализации IPSec обычно либо скрывает эти БД, либо представляет их в более дружественном виде.
Туннелирование, или инкапсуляция, - это обычный метод защиты для сетей с маршрутизацией пакетов. Он заключается в том, что па кеты, передаваемые в сети, «оборачиваются» в новые пакеты, так как к первоначальному пакету приписывается новый заголовок и, возможно, хвостовик. Исходный пакет целиком становится заполне нием нового пакега более низкоуровневого протокола (рис. 4.2).
НоnьпlIP·
I заголовок
Исходная (пнкапсулпрованная) дейгаграмма становится эаполнением нового ПЭ-Пilкerа
Рис. 4.2. Принцип туннелирования (инкапсуляции) протоколов
Туннелирование часто используется для того, чтобы перенести трафик какого-либо протокола через сеть, которая не поддерживает этот протокол непосредственно. Например, протоколы NetВIOS или IPX могут быть инкапсулированы в IP-пакеты для переноса их через глобальную сеть, построенную в архитектуре TCPIIP. Туннелирова-
4. КРllлmографl/чеСКlIе протоколы в ::JЛекmРОlI110i'i КОМ.АfерЦIlU и 8 докумеumообороmе 225 ние можно использовать и для целей защиты информации. Так и происходит в архитектуре IPSec: туннелирование применяется для того, чтобы обеспечить сплошную защиту переда-ваемых пакетов, включая и заголовки инкапсулируемых пакетов. Если пакеты шиф
руются, то злоумышленник не может извлечь оттуда, к примеру, ад рес получателя пакетов (в отсутствие туннелирования ои это легко смог бы сделать). Таким образом, от постороннего наблюдателя мо жет быть скрыта внутренняя структура частной сети.
Туннелирование требует промежуточной обработки исходного пакста при маршрутизации. Адрес получателя, указанный во внеш нем заголовке, обычно является адресом межсетевого экрана или маршрутизатора, поддерживающего архитектуру IPSec. Он получает инкапсулированный пакет, извлекает из него содержимое исходного пакета и посылает его оконечному получателю. Дополнительные за траты на обработку компенсируются повышением уровня безопас
ности.
Замечательным преимуществом туннелирования IР-пакетов ЯВ ляется способность обмениваться пакетами с частными IP-адресами между двумя внутренними сетями организаций через публичный канал, который требует, чтобы узлы имели уникальные глобальные адреса. Так как инкапсулированный заголовок не обрабатывается маршрутизаторами в сети Интернет, достаточно, чтобы только око нечные точки туннеля (шлюзы) имели бы глобально присвоенные адреса. Хосты в частных сетях (интранет-сетях) за ними могут иметь частные адреса (например, вида 10.х.х.х). Так как глобальные IP- адреса становятся дефицитными, такой метод взаимосвязи сетей приобретает большое значение. Модель туннелирования в архитек туре безопасности IPSec описана в рекомендации RFC 2003 - «IP Епсарвшапоп within ТР».
Далее мы рассмотрим протоколы архитектуры IPSec, более ин тересные с технической, нежели с алгоритмической точки зрения, так как их криптографическая «начинка» довольно проста.
Итак, первым компонентом архитектуры безопасности IPSec яв ляется протокол АН. Он используется для того, чтобы обеспечить целостность и подлинность IP-деЙтаграмм. С его помощью также возможна защита и от повтора пакетов. Хотя его использование рас сматривается как необязательное, сервис защиты от повтора пакетов
226
Запечников С. В. Криптографическиепротоколы u tlX применение
должен быть реализован в любой системе, совместимой с архитек турой IPSec. Сервисы не требуют установки соединений, следова тельно, должны быть обеспечены для каждого пакета в отдельности. Протокол АН используется в двух режимах: транспортном и тун
нельном.
Протокол АН обеспечивает подлинность для возможно большей части IP-деЙтаграмм. В транспортном режиме некоторые поля ТР
заголовка изменяются при маршрутизации, поэтому их значения не
могут быть предсказаны получателем. Эти поля называются nере менними (Jnutable) и не защищаются протоколом АН. Персменные поля пакета 1Ру4 таковы:
поле, указывающее тип сервиса (Туре of service - TOS); поле флагов;
поле смещения фрагмента (Frаgшеnt offset); поле времени жизни пакета (Тппе to live - TTL);
поле контрольной суммы заголовка (header сhесksuш).
Когда требуется защита этих полей, должно быть использовано туннелирование. Заполнение IР-пакета рассматривается как неизме няемое и в любом случае защищается методом АН.
Протокол АН идентифицируетсяномером протокола 51, присво енным IANA. Заголовок протокола непосредственно предшествует заголовку протоколаАН, содержащемуэту величинув своих полях.
Обработка методом, предусмотреннымпротоколом АН, приме нима только к нефрагментированнымIР-пакетам. Однако IР-пакет с заголовком АН может быть фрагментирован промежуточным мар шрутизатором. В этом случае получатель сначала собирает пакет, а затем применяетк нему обработку в соответствии с методом, пре дусмотреннымАН. Если при начале обработки оказывается, что IP- пакет предположительно разбит на фрагменты (поле смещения не нулевое или флаг More fragments установлен в единицу), он удаляет ся. Это предотвращает атаку методом перекрытия фрагментов (overlapping fragment attack), которая возможна при некорректном ис пользовании алгоритма сборки фрагментов и позволяет искажать пакеты и пересылать их через МЭ.
Пакеты, которые не проходят аутентификацию, удаляются и ни когда не доставляются на верхние уровни. Этот режим значительно
уменьшает вероятность успешного проведения атак, приводящих
4. Криптографическиепротоколы вэлекmрОIlJlоii коммерции II в докумеllЛ100бороmе 227 К отказу в обслуживании, цель которых заключается в том, чтобы блокировать связь с хостом или шлюзом, наводняя их «поддельны
ми» пакетами.
Формат АН-заголовка (рис. 4.3) описан в RFC 2402. В него вхо-
дят следующие поля:
«Следующий заголовок» - Next hcader (8 бит); «Длина заполнения пакета» - Payload length (8 бит); Зарезервированное поле (16 бит, установленных в О);
«Индекс параметра безопасности» - Security Рагагпегег Index
(SPI) (32 бита);
«Порядковый номер пакета в последовательности» - Sequence пшпэег (32 бита);
«Код аутентификации сообщения» - Authentication data (32 бита
Рис. 4.3. Формат заголовка протокола АН в соответствии с RFC 2402
Заголовок АН в транспортном режиме вставляется в пакет сра зу после заголовка IP-пакета (рис. 4.4). Если дейтаграмма уже имеет заголовок IPScc, заголовок АН помещается перед ним. Транспорт ный режим используется хосгами, но не шлюзами. Шлюзам не тре буется поддерживать транспортный режим. Преимуществом транс
портного режима является меньшая вычислительная сложность, не
достатком - отсутствие проверки подлинности изменяемых полей.
228 Запечников С. В. Криптографическиепротоколы 11 их примененив
]р·зяrолово"
Злполненпе ]Р·п:п<еТiI
Исходная1Р-де[ПnГРilмма
I
IP-заrолово!'
Обеспечена аутеншчносгь (ьроме изменяемых полей)
Рис. 4.4. 3аг01l0601<. протокола АН в транспортном режиме
АН в туннельномрежиме использует ранее рассмотренную кон цепцию туннелирования. При этом конструируется новая IP-дей таграмма, в то время как исходная становится ее заполнением. АН в транспортном режиме применяется к полученной' дейтаграмме (рис. 4.5). Туннельный режим используется всякий раз, когда око нечным узлом защищенной ассоциации является шлюз. Так, между двумя МЭ всегда используется туннельный режим.
Заполнение
IP-пжетn
Туннелнрован
{Р
Заполнение IP-ШlКета
им дейтаграмма
заголовок
Дейгаграмма с
~b~~;~:~~~~~~~~~~~~~~~~~~~~~~~~~=~~:::==;IP-
заголовок
Обеспечена аугеншчностъ (кроме изменяемых попей в новом IP-заrо.повке)
Рис. 4.5. Заголовок протокола АН в туннельномрежиме
Шлюзы часто также поддерживают и транспортный режим. Этот режим разрешен, когда шлюз действует как ХОСТ, т. е. в случаях, ко гда трафик предназначен самому шлюзу. Например, команды SNМP могут быть направлены шлюзу, используя транспортный режим.
В туннельном' режиме IР-адреса внешних заголовков не обяза тельно должны быть теми же самыми, что и адреса внутренних за головков. Например, два шлюза могут организовать АН-туннель, который используется для того, чтобы гарантировать подлинность
