9. Лекция: Спецификации Internet-сообщества IPsec Архитектура средств безопасности IP-уровня
В курсе "Основы информационной безопасности" [91] указывалось, что практически все механизмы сетевой безопасности могут быть реализованы на третьем уровне эталонной модели ISO/OSI. Более того, IP-уровень можно считать оптимальным для размещения защитных средств, поскольку при этом достигается удачный компромисс между защищенностью, эффективностью функционирования и прозрачностью для приложений.
Стандартизованными механизмами IP-безопасности могут (и должны)пользоваться протоколы более высоких уровней и, в частности, управляющие протоколы, протоколы конфигурирования и маршрутизации.
Средства безопасности для IP описываются семейством спецификаций IPsec, разработанных рабочей группой IP Security.
Протоколы IPsec обеспечивают управление доступом , целостность вне соединения, аутентификацию источника данных, защиту от воспроизведения, конфиденциальность и частичную защиту от анализа трафика.
Архитектура средств безопасности для IP-уровня специфицирована в документе [63]. Ее основные составляющие представлены на рис. 9.1. Это прежде всего протоколы обеспечения аутентичности (протокол аутентифицирующего заголовка - Authentication Header, AH) и конфиденциальности (протокол инкапсулирующей защиты содержимого - Encapsulating Security payload, ESp), а также механизмы управления криптографическими ключами. На более низком архитектурном уровне располагаются конкретные алгоритмы шифрования, контроля целостности и аутентичности. Наконец, роль фундамента выполняет так называемый домен интерпретации (Domain of Interpretation, DOI), являющийся, по сути, базой данных, хранящей сведения об алгоритмах, их параметрах, протокольных идентификаторах и т.п.
Рис. 9.1. Основные элементы архитектуры средств безопасности IP-уровня
Деление на уровни важно для всех аспектов информационных технологий. Там же, где участвует еще и криптография, важность возрастает вдвойне, поскольку приходится считаться не только с чисто техническими факторами, но и с особенностями законодательства различных стран, с ограничениями на экспорт и/или импорт криптосредств (см. курс "Основы информационной безопасности" [91]).
Протоколы обеспечения аутентичности и конфиденциальности в IPsec не зависят от конкретных криптографических алгоритмов. (Более того, само деление на аутентичность и конфиденциальность предоставляет и разработчикам, и пользователям дополнительную степень свободы в ситуации, когда к криптографическим относят только шифровальные средства.) В каждой стране могут применяться свои алгоритмы, соответствующие национальным стандартам, но для этого, как минимум, нужно позаботиться об их регистрации в домене интерпретации.
Алгоритмическая независимость протоколов, к сожалению, имеет и оборотную сторону, состоящую в необходимости предварительного согласования набора применяемых алгоритмов и их параметров, поддерживаемых общающимися сторонами. Иными словами, стороны должны выработать общий контекст безопасности (Security Association, SA) и затем использовать такие его элементы, как алгоритмы и их ключи. За формирование контекстов безопасности в IPsec отвечает особое семейство протоколов, которое будет рассмотрено в последующих разделах.
Протоколы обеспечения аутентичности и конфиденциальности могут применяться в двух режимах: транспортном и туннельном. В первом случае защищается только содержимое пакетов и, быть может, некоторые поля заголовков. Как правило, транспортный режим используется хостами. В туннельном режиме защищается весь пакет - он инкапсулируется в другой IP-пакет. Туннельный режим обычно реализуют на специально выделенных защитных шлюзах (в роли которых могут выступать маршрутизаторы или межсетевые экраны, см. курс "Основы информационной безопасности" [91]).
В последующих разделах мы подробно рассмотрим основные элементы IPsec.
Контексты безопасности и управление ключами
Формирование контекстов безопасности в IPsec разделено на две фазы. Сначала создается управляющий контекст, назначение которого - предоставить доверенный канал (в терминологии "Общих критериев", см., например, [87]), т. е. аутентифицированный, защищенный канал для выработки (в рамках второй фазы) протокольных контекстов и, в частности, для формирования криптографических ключей, используемых протоколами AH и ESp.
В принципе, для функционирования механизмов IPsec необходимы только протокольные контексты; управляющий играет вспомогательную роль. Более того, явное выделение двух фаз утяжеляет и усложняет формирование ключей, если рассматривать последнее как однократное действие. Тем не менее, из архитектурных соображений управляющие контексты не только могут, но и должны существовать, поскольку обслуживают все протокольные уровни стека TCp/IP, концентрируя в одном месте необходимую функциональность. Первая фаза начинается в ситуации, когда взаимодействующие стороны не имеют общих секретов (общих ключей) и не уверены в аутентичности друг друга. Если с самого начала не создать доверенный канал, то для выполнения каждого управляющего действия с ключами (их модификация, выдача диагностических сообщений и т.п.) в каждом протоколе (AH, ESp, TLS и т.д.) этот канал придется формировать заново.
Общие вопросы формирования контекстов безопасности и управления ключами освещаются в спецификации [70] - "Контексты безопасности и управление ключами в Internet" (Internet Security Association and Key Management protocol, ISAKMp). Здесь вводятся две фазы выработки протокольных ключей, определяются виды управляющих информационных обменов и используемые форматы заголовков и данных. Иными словами, в [70] строится протокольно-независимый каркас.
Существует несколько способов формирования управляющего контекста. Они различаются двумя показателями:
используемым механизмом выработки общего секретного ключа;
степенью защиты идентификаторов общающихся сторон.
В простейшем случае секретные ключи задаются заранее (ручной метод распределения ключей). Для небольших сетей такой подход вполне работоспособен, но он не является масштабируемым. Последнее свойство может быть обеспечено при автоматической выработке и распределении секретных ключей в рамках протоколов, основанных на алгоритме Диффи-Хелмана (см. [91]). Пример тому - "Протокол для обмена ключами в Internet " (The Internet Key Exchange, IKE, [46]).
При формировании управляющего контекста идентификаторы общающихся сторон (например, IP-адреса) могут передаваться в открытом виде или шифроваться. Поскольку ISAKMp предусматривает функционирование в режиме клиент/сервер (т. е. ISAKMp-сервер может формировать контекст для клиента), сокрытие идентификаторов в определенной степени повышает защищенность от пассивного прослушивания сети.
Последовательность передаваемых сообщений, позволяющих сформировать управляющий контекст и обеспечивающих защиту идентификаторов, выглядит следующим образом (см. рис. 9.2).
Рис. 9.2. Формирование управляющего контекста.
В первом сообщении (1) инициатор направляет предложения по набору защитных алгоритмов и конкретных механизмов их реализации. Предложения упорядочиваются по степени предпочтительности (для инициатора). В ответном сообщении (2) партнер информирует о сделанном выборе - какие алгоритмы и механизмы его устраивают. Для каждого класса защитных средств (генерация ключей, аутентификация, шифрование) выбирается только один элемент.
В сообщениях (3) и (4) инициатор и партнер отправляют свои части ключевого материала, необходимые для выработки общего секретного ключа (мы опускаем детали, специфичные для алгоритма Диффи-Хелмана). Одноразовые номера (nonce) представляют собой псевдослучайные величины, служащие для защиты от воспроизведения сообщений.
Посредством сообщений (5) и (6) происходит обмен идентификационной информацией, подписанной (с целью аутентификации) секретным ключом отправителя и зашифрованной выработанным на предыдущих шагах общим секретным ключом. Для аутентификации предполагается использование сертификатов открытых ключей. Отметим, что в число подписываемых данных входят одноразовые номера.
В представленном виде протокол формирования управляющего контекста защищает от атак, производимых нелегальным посредником, а также от нелегального перехвата соединений. Для защиты от атак на доступность, для которых характерно прежде всего навязывание интенсивных вычислений, присущих криптографии с открытым ключом, применяются так называемые идентифицирующие цепочки (cookies). Эти цепочки, формируемые инициатором и его партнером с использованием текущего времени (для защиты от воспроизведения), на самом деле присутствуют во всех ISAKMp-сообщениях и в совокупности идентифицируют управляющий контекст (в первом сообщении, по понятным причинам, фигурирует только цепочка инициатора). Согласно спецификациям [70], заголовок ISAKMp-сообщения имеет вид, изображенный на рис. 9.3. Если злоумышленник пытается "завалить" кого-либо запросами на создание управляющего контекста, подделывая при этом свой IP-адрес, то в сообщении (3) (см. выше рис. 9.2) он не сможет предъявить идентифицирующую цепочку партнера, поэтому до выработки общего секретного ключа и, тем более, электронной подписи и полномасштабной проверки аутентичности дело попросту не дойдет.
Рис. 9.3. Формат заголовка ISAKMp-сообщения.
Управляющие контексты являются двунаправленными в том смысле, что любая из общающихся сторон может инициировать с их помощью выработку новых протокольных контекстов или иные действия. Для передачи ISAKMp-сообщений используется любой протокол, однако в качестве стандартного принят UDp с номером порта 500.
Протокольные контексты и политика безопасности
Системы, реализующие IPsec, должны поддерживать две базы данных:
базу данных политики безопасности (Security policy Database, SpD);
базу данных протокольных контекстов безопасности (Security Association Database, SAD).
Все IP-пакеты (входящие и исходящие) сопоставляются с упорядоченным набором правил политики безопасности. При сопоставлении используется фигурирующий в каждом правиле селектор - совокупность анализируемых полей сетевого уровня и более высоких протокольных уровней. Первое подходящее правило определяет дальнейшую судьбу пакета:
пакет может быть ликвидирован;
пакет может быть обработан без участия средств IPsec;
пакет должен быть обработан средствами IPsec с учетом набора протокольных контекстов, ассоциированных с правилом.
Таким образом, системы, реализующие IPsec, функционируют как межсетевые экраны, фильтруя и преобразуя потоки данных на основе предварительно заданной политики безопасности.
Далее мы детально рассмотрим контексты и политику безопасности, а также порядок обработки сетевых пакетов.
Протокольный контекст безопасности в IPsec - это однонаправленное "соединение" (от источника к получателю), предоставляющее обслуживаемым потокам данных набор защитных сервисов в рамках какого-то одного протокола (AH или ESp). В случае симметричного взаимодействия партнерам придется организовать два контекста (по одному в каждом направлении). Если используются и AH, и ESp, потребуется четыре контекста.
Элементы базы данных протокольных контекстов содержат следующие поля (в каждом конкретном случае некоторые значения полей будут пустыми):
используемый в протоколе AH алгоритм аутентификации, его ключи и т.п.;
используемый в протоколе ESp алгоритм шифрования, его ключи, начальный вектор и т.п.;
используемый в протоколе ESp алгоритм аутентификации, его ключи и т.п.;
время жизни контекста;
режим работы IPsec: транспортный или туннельный;
максимальный размер пакетов;
группа полей (счетчик, окно, флаги) для защиты от воспроизведения пакетов.
Пользователями протокольных контекстов, как правило, являются прикладные процессы. Вообще говоря, между двумя узлами сети может существовать произвольное число протокольных контекстов, так как число приложений в узлах произвольно. Отметим, что в качестве пользователей управляющих контекстов обычно выступают узлы сети (поскольку в этих контекстах желательно сосредоточить общую функциональность, необходимую сервисам безопасности всех протокольных уровней эталонной модели для управления криптографическими ключами).
Управляющие контексты - двусторонние, т. е. любой из партнеров может инициировать новый ключевой обмен. Пара узлов может одновременно поддерживать несколько активных управляющих контекстов, если имеются приложения с существенно разными криптографическими требованиями. Например, допустима выработка части ключей на основе предварительно распределенного материала, в то время как другая часть порождается по алгоритму Диффи-Хелмана.
Протокольный контекст для IPsec идентифицируется целевым IP-адресом, протоколом (AH или ESp), а также дополнительной величиной - индексом параметров безопасности (Security parameter Index, SpI). Последняя величина необходима, поскольку могут существовать несколько контекстов с одинаковыми IP-адресами и протоколами. Далее будет показано, как используются индексы SpI при обработке входящих пакетов.
IPsec обязывает поддерживать ручное и автоматическое управление контекстами безопасности и криптографическими ключами. В первом случае все системы заранее снабжаются ключевым материалом и иными данными, необходимыми для защищенного взаимодействия с другими системами. Во втором - материал и данные вырабатываются динамически, на основе определенного протокола - IKE [46], поддержка которого обязательна.
Протокольный контекст создается на базе управляющего с использованием ключевого материала и средств аутентификации и шифрования последнего. В простейшем случае, когда протокольные ключи генерируются на основе существующих, последовательность передаваемых сообщений выгладит так, как показано на рис. 9.4.
Рис. 9.4. Формирование протокольного контекста.
Когда вырабатывался управляющий контекст, для него было создано три вида ключей:
SKEYID_d - ключевой материал, используемый для генерации протокольных ключей;
SKEYID_a - ключевой материал для аутентификации;
SKEYID_e - ключевой материал для шифрования.
Все перечисленные виды ключей задействованы в обмене, показанном на рис. 9.4. Ключом SKEYID_e шифруются сообщения. Ключ SKEYID_a служит аргументом хэш-функций и тем самым аутентифицирует сообщения. Наконец, протокольные ключи - результат применения псевдослучайной (хэш) функции к SKEYID_d с дополнительными параметрами, в число которых входят одноразовые номера инициатора и партнера. В результате создание протокольного контекста оказывается аутентифицированным, защищенным от несанкционированного ознакомления, от воспроизведения сообщений и от перехвата соединения.
Сообщения (1) и (2) могут нести дополнительную нагрузку, например, данные для выработки "совсем новых" секретных ключей или идентификаторы клиентов, от имени которых ISAKMp-серверы формируют протокольный контекст. В соответствии с протоколом IKE, за один обмен (состоящий из трех показанных на рис. 9.4 сообщений) формируется два однонаправленных контекста - по одному в каждом направлении. Получатель контекста задает для него индекс параметров безопасности (SpI), помогающий находить контекст для обработки принимаемых пакетов IPsec.
Строго говоря, протокольные контексты играют вспомогательную роль, будучи лишь средством проведения в жизнь политики безопасности; она должна быть задана для каждого сетевого интерфейса с задействованными средствами IPsec и для каждого направления потоков данных (входящие/исходящие). Согласно спецификациям IPsec [63], политика рассчитывается на бесконтекстную (независимую) обработку IP-пакетов, в духе современных фильтрующих маршрутизаторов. Разумеется, должны существовать средства администрирования базы данных SpD, так же, как и средства администрирования базы правил межсетевого экрана, однако этот аспект не входит в число стандартизуемых.
С внешней точки зрения, база данных политики безопасности (SpD) представляет собой упорядоченный набор правил. Каждое правило задается как пара:
совокупность селекторов;
совокупность протокольных контекстов безопасности.
Селекторы служат для отбора пакетов, контексты задают требуемую обработку. Если правило ссылается на несуществующий контекст, оно должно содержать достаточную информацию для его (контекста) динамического создания. Очевидно, в этом случае требуется поддержка автоматического управления контекстами и ключами. В принципе, функционирование системы может начинаться с задания базы SpD при пустой базе контекстов (SAD); последняя будет наполняться по мере необходимости.
Дифференцированность политики безопасности определяется селекторами, употребленными в правилах. Например, пара взаимодействующих хостов может использовать единственный набор контекстов, если в селекторах фигурируют только IP-адреса; с другой стороны, набор может быть своим для каждого приложения, если анализируются номера TCp- и UDp-портов. Аналогично, два защитных шлюза способны организовать единый туннель для всех обслуживаемых хостов или же расщепить его (путем организации разных контекстов) по парам хостов или даже приложений.
Все реализации IPsec должны поддерживать селекцию следующих элементов:
исходный и целевой IP-адреса (адреса могут быть индивидуальными и групповыми, в правилах допускаются диапазоны адресов и метасимволы "любой");
имя пользователя или узла в формате DNS или X.500;
транспортный протокол;
номера исходного и целевого портов (здесь также могут использоваться диапазоны и метасимволы).
Обработка исходящего и входящего трафика, согласно [63], не является симметричной. Для исходящих пакетов просматривается база SpD, находится подходящее правило, извлекаются ассоциированные с ним протокольные контексты и применяются соответствующие механизмы безопасности. Во входящих пакетах для каждого защитного протокола уже проставлено значение SpI, однозначно определяющее контекст. Просмотр базы SpD в таком случае не требуется; можно считать, что политика безопасности учитывалась при формировании соответствующего контекста. (Практически это означает, что ISAKMp-пакеты нуждаются в особой трактовке, а правила с соответствующими селекторами должны быть включены в SpD.)
Отмеченная асимметрия, на наш взгляд, отражает определенную незавершенность архитектуры IPsec. В более раннем, по сравнению с [63], документе RFC 1825 понятия базы данных политики безопасности и селекторов отсутствовали. В новой редакции сделано полшага вперед - специфицирован просмотр базы SpD как обязательный для каждого исходящего пакета, но не изменена обработка входящих пакетов. Конечно, извлечение контекста по индексу SpI эффективнее, чем просмотр набора правил, но при таком подходе, по меньшей мере, затрудняется оперативное изменение политики безопасности. Что касается эффективности просмотра правил, то ее можно повысить методами кэширования, широко используемыми при реализации IP.
Возможно, еще более серьезным недостатком является невозможность обобщения предложенных процедур формирования контекстов (управляющих и протокольных) на многоадресный случай. В текущих спецификациях IPsec смешиваются две разные вещи - область действия контекста (сейчас это односторонний или двусторонний поток данных) и способ его идентификации (по индексу SpI или паре идентифицирующих цепочек). Получается, что способ идентификации (именования) навязывает трактовку области действия, что представляется неверным. На наш взгляд, вопросы именования могут решаться локально, а область действия контекста потенциально должна распространяться на произвольное число партнеров.
Обеспечение аутентичности IP-пакетов
Протокол аутентифицирующего заголовка (Authentication Header, AH, см. [61]) служит в IPsec для обеспечения целостности пакетов и аутентификации источника данных, а также для защиты от воспроизведения ранее посланных пакетов. AH защищает данные протоколов более высоких уровней и те поля IP-заголовков, которые не меняются на маршруте доставки или меняются предсказуемым образом. (Отметим, что число "непредсказуемых" полей невелико - это prio. (Traffic Class), Flow Label и Hop Limit. Предсказуемо меняется целевой адрес при наличии дополнительного заголовка исходящей маршрутизации.)
Формат заголовка AH показан на рис. 9.5.
Рис. 9.5. Формат заголовка AH.
Поясним смысл полей, специфичных для AH:
индекс параметров безопасности (SpI) - 32-битное значение, выбираемое получателем пакетов с AH-заголовками в качестве идентификатора протокольного контекста (см. выше раздел "Протокольные контексты и политика безопасности");
порядковый номер - беззнаковое 32-битное целое, наращиваемое от пакета к пакету. Отправитель обязан поддерживать этот счетчик, в то время как получатель может (но не обязан) использовать его для защиты от воспроизведения. При формировании протокольного контекста обе взаимодействующие стороны делают свои счетчики нулевыми, а потом согласованным образом увеличивают их. Когда значение порядкового номера становится максимально возможным, должен быть сформирован новый контекст безопасности;
аутентификационные данные - поле переменной длины, содержащее имитовставку (криптографическую контрольную сумму, Integrity Check Value, ICV) пакета; способ его вычисления определяется алгоритмом аутентификации.
Для вычисления аутентифицированных имитовставок могут применяться различные алгоритмы. Спецификациями [61] предписывается обязательная поддержка двух алгоритмов, основанных на применении хэш-функций с секретными ключами:
HMAC-MD5 (Hashed Message Authentication Code - Message Digest version 5, см. [68]);
HMAC-SHA-1 (Hashed Message Authentication Code - Secure Hash Algorithm version 1, см. [69]).
Мы не будем описывать процесс вычисления хэш-функций, лишь еще раз обратим внимание на необходимость приведения национальных криптографических стандартов, нормативно-правовой базы и практических работ в соответствие со сложившейся международной практикой.
Обеспечение конфиденциальности сетевого трафика
Протокол инкапсулирующей защиты содержимого (Encapsulating Security payload, ESp, см. [62]) предоставляет три вида сервисов безопасности:
обеспечение конфиденциальности (шифрование содержимого IP-пакетов, а также частичная защита от анализа трафика путем применения туннельного режима);
обеспечение целостности IP-пакетов и аутентификации источника данных;
обеспечение защиты от воспроизведения IP-пакетов.
Можно видеть, что функциональность ESp шире, чем у AH (добавляется шифрование); взаимодействие этих протоколов мы подробнее рассмотрим позже. Здесь же отметим, что ESp не обязательно предоставляет все сервисы, но либо конфиденциальность, либо аутентификация должны быть задействованы. Формат заголовка ESp выглядит несколько необычно (см. рис. 9.6). Причина в том, что это не столько заголовок, сколько обертка (инкапсулирующая оболочка) для зашифрованного содержимого. Например, ссылку на следующий заголовок нельзя выносить в начало, в незашифрованную часть, так как она лишится конфиденциальности.
Рис. 9.6. Формат заголовка ESp.
Поля "Индекс параметров безопасности (SpI)", "Порядковый номер" и "Аутентификационные данные" (последнее присутствует только при включенной аутентификации) имеют тот же смысл, что и для AH. Правда, ESp аутентифицирует лишь зашифрованную часть пакета (плюс два первых поля заголовка).
Применение протокола ESp к исходящим пакетам можно представлять себе следующим образом. Назовем остатком пакета ту его часть, которая помещается после предполагаемого места вставки заголовка ESp. При этом не важно, какой режим используется - транспортный или туннельный. Шаги протокола таковы:
остаток пакета копируется в буфер;
к остатку приписываются дополняющие байты, их число и номер (тип) первого заголовка остатка, с тем чтобы номер был прижат к границе 32-битного слова, а размер буфера удовлетворял требованиям алгоритма шифрования;
текущее содержимое буфера шифруется;
в начало буфера приписываются поля "Индекс параметров безопасности (SpI)" и "Порядковый номер" с соответствующими значениями;
пополненное содержимое буфера аутентифицируется, в его конец помещается поле "Аутентификационные данные";
в новый пакет переписываются начальные заголовки старого пакета и конечное содержимое буфера.
Таким образом, если в ESp включены и шифрование, и аутентификация, то аутентифицируется зашифрованный пакет. Для входящих пакетов действия выполняются в обратном порядке, т. е. сначала производится аутентификация. Это позволяет не тратить ресурсы на расшифровку поддельных пакетов, что в какой-то степени защищает от атак на доступность.
Два защитных протокола - AH и ESp - могут комбинироваться разными способами. При выборе транспортного режима AH должен использоваться после ESp (аналогично тому, как в рамках ESp аутентификация идет следом за шифрованием). В туннельном режиме AH и ESp применяются, строго говоря, к разным (вложенным) пакетам, число допустимых комбинаций здесь больше (хотя бы потому, что возможна многократная вложенность туннелей с различными начальными и/или конечными точками).
Совокупность механизмов, предлагаемая в рамках IPsec, является весьма мощной и гибкой. IPsec - это основа, на которой может строиться реализация виртуальных частных сетей, обеспечиваться защищенное взаимодействие мобильных систем с корпоративной сетью, защита прикладных потоков данных и т.п.
|
