Анализ защищенности

Анализ защищенности - сравнительно новый, но весьма популярный сервис безопасности, помогающий реализовать профилактический подход к обеспечению защиты информационных систем. Суть его весьма проста, но "Общими критериями" он поддержан крайне слабо. Посмотрим, как можно изменить это положение.

Предлагается ввести новый класс функциональных требований - FPA: анализ защищенности. В нем может быть три семейства:

FPA_HLP: описание уязвимости, выдача рекомендаций по ее устранению; FPA_RAD: автообнаружение контролируемых объектов; FPA_SPA: анализ характеристик защищенности.

Семейство FPA_HLP может состоять из одного компонента:

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

Для семейства FPA_HLP предусмотрено многократное использование (например, для выдачи сведений об атаках средствами активного аудита). Его роль сравнима с ролью комментариев в языках программирования; отсутствие подобного семейства, на наш взгляд, является методологической недоработкой авторов "Общих критериев". Выдача пояснений полезна не только для анализа защищенности, но и для выбора реакции на обнаруженную атаку. (Почему система анализа решила, что атака имеет место? Какие правила при этом сработали? Насколько серьезна обнаруженная атака? На все эти вопросы администратор безопасности должен получить оперативные, информативные ответы.)

Семейство FPA_RAD может располагать одним компонентом:

FPA_RAD.1 - автообнаружение компонентов анализируемой ИС, описание которых содержится в базе данных системы анализа защищенности.

В семействе FPA_SPA возможно присутствие трех компонентов:

FPA_SPA.1 - проверка наличия в системе и/или сети сущностей, указанных в базе данных системы анализа защищенности (имеются в виду небезопасные сервисы, такие, например, как TFTP); FPA_SPA.2 - анализ характеристик выявленных сущностей (номеров версий, конфигурационных параметров, атрибутов доступа, слабых паролей - и здесь анализируется то, что перечислено в базе данных). Правила для анализа могут быть сложными, охватывающими несколько характеристик; FPA_SPA.3 - проверка реакции объекта на выполнение определенных действий (имитация атак, перечисленных в базе).

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

<

Анонимизаторы

Анонимизаторы предназначены для выполнения функциональных требований приватности (класс FPR "Общих критериев"). В данном разделе, основываясь на статье [74] и профиле защиты [48], мы рассмотрим одну из разновидностей анонимизаторов - сеть серверов пересылки, обеспечивающую приватность пользователей электронной почты.

Вероятно, приватность - это единственный класс функциональных требований ОК, направленных не на обеспечение безопасности иерархически организованных, жестко администрируемых систем, а на защиту специфических интересов пользователей информационных сервисов. В "Оранжевой книге" Министерства обороны США и Руководящих документах Гостехкомиссии России подобных требований не было, поэтому необходимо накапливать опыт по их применению, что придает работам [74] и [48] особую ценность. Происходит становление так называемой многоаспектной информационной безопасности, когда делается попытка учесть весь спектр интересов (порой конфликтующих между собой) всех субъектов информационных отношений, а также все виды конфигураций ИС, в том числе децентрализованные, не имеющие единого центра управления.

Напомним, что класс FPR содержит четыре семейства: FPR_ANO (анонимность - возможность совершать действия, не раскрывая идентификационных данных пользователя), FPR_PSE (псевдонимность - анонимность с сохранением подотчетности), FPR_UNL (невозможность ассоциации - анонимность с сокрытием связи между действиями одного пользователя), FPR_UNO (скрытность, или ненаблюдаемость - сокрытие самого факта использования ресурса или услуги). Псевдонимность полезна, например, когда за многократное обращение к каким-то специфическим платным услугам полагаются скидки. Невозможность ассоциации позволяет защититься от раскрытия личности пользователя путем анализа профиля его поведения. Назначение семейств FPR_ANO и FPR_UNO очевидно.

Сеть серверов пересылки почты состоит из независимо администрируемых узлов. Отправитель определяет в ней путь сообщения, которое шифруется таким образом, что каждому серверу известны только предыдущий и следующий узлы.
В результате достигается невозможность установления ассоциации между отправителем и получателем. Если в сообщении отсутствуют идентификационные данные отправителя, то обеспечиваются анонимность, невозможность ассоциации и, отчасти, скрытность. Псевдонимность может быть реализована путем применения особым образом заданных обратных адресов. Отметим, что на тех же принципах организуется работа анонимизаторов для других информационных сервисов, в частности, для Web-доступа. Существуют свободно распространяемые (Mixmaster) и коммерческие (компании Zero Knowledge Systems) реализации сетей серверов пересылки.

Сеть серверов пересылки можно рассматривать двояко: изнутри и извне. Традиционный взгляд изнутри, с точки зрения гипотетического администратора сети, обязанного обеспечить ее безопасность и высокую доступность, ведет к традиционному же профилю защиты, требования которого противоречат приватности. Действительно, для защиты сети от атак на доступность необходимо выявлять подозрительную активность путем накопления и анализа регистрационной информации, уметь прослеживать пользователей и т.п. В силу указанных причин в данном разделе мы будем придерживаться взгляда извне, с точки зрения пользователя сервиса анонимизации; с этих позиций и разработан профиль [48].

Для сети серверов пересылки сообщений выделяются следующие специфические угрозы безопасности:

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

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



Формулируются два специфических положения политики безопасности:

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

Перечислим специфические цели безопасности:

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

Специфические цели безопасности для среды:

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

Чтобы лучше понять приведенные ниже специфические функциональные требования, целесообразно помнить, что рассматриваемый профиль защиты сформирован с позиций пользователя, так что в объект оценки (ОО) входят как серверы пересылки, так и клиентские системы.

Все потоки данных контролируются функциями безопасности ОО; экспорта или импорта данных не происходит.

В пределах области действия функций безопасности имеют место следующие виды операций:

передача сообщения клиентской системой серверу пересылки; пересылка сообщений, а также управляющей информации (в том числе ключевой), между серверами; доставка сообщения с сервера на клиентскую систему; обработка сервером пересылки (транзитных) сообщений; операции, выполняемые сервером с криптографическими ключами: генерация, распространение, хранение, доступ, использование, уничтожение; порождение сервером пересылки фиктивных сообщений.

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

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

Специфические функциональные требования состоят в следующем.

полное управление доступом (FDP_ACC.2). Политика принудительного управления доступом должна распространяться на всех субъектов (серверы пересылки, клиентское ПО, пользователи, администраторы), все объекты (в том числе на содержание и маршрутную информацию сообщений) и все операции; ограниченное управление информационными потоками (FDP_IFC.1). Должна проводиться в жизнь политика борьбы со скрытыми каналами применительно к серверам пересылки, клиентскому ПО, сообщениям, передаче и приему сообщений (FDP_IFC.1.1); частичное устранение неразрешенных информационных потоков (FDP_IFF.4). Политику борьбы со скрытыми каналами необходимо внедрять, чтобы уменьшить до заданных пределов утечку информации о работе пользователей с сетью пересылки, возникающую за счет анализа периферийных потоков данных (FDP_IFF.4.1).


Получение профилей поведения компонентов сети пересылки путем анализа периферийных потоков данных должно быть невозможным (FDP_IFF.4.2); полное управление временем хранения данных (FDP_IRC.2). Все объекты, нужные для нормальной работы сети пересылки, удаляются сразу после завершения операций с ними. Отметим, что это не просто специфическое, но новое функциональное требование, предложенное автором профиля защиты; управление атрибутами безопасности (FMT_MSA.1). Согласно политике принудительного управления доступом, только пользователь, сгенерировавший данные, может выполнять операции над их атрибутами безопасности, в число которых входят маршрут сообщения и его рандомизация, минимальное число пересылок, число отправляемых избыточных сообщений, параметры потоков данных и криптографических алгоритмов и т.п. (FMT_MSA.1.1); анонимность без запроса информации (FPR_ANO.2). Должны обеспечиваться невозможность определения подлинного имени отправителя сообщения, обрабатываемого сетью серверов пересылки (FPR_ANO.2.1), а также невозможность отслеживания и анонимность пересылки сообщений для всех пользователей без запроса какой-либо ссылки на подлинное имя пользователя (FPR_ANO.2.2); размещение информационных ресурсов (FPR_TRD.2). Сеть пересылки должна состоять из отдельных взаимодействующих частей, в каждой из которых реализуются свои правила аутентификации и управления доступом (FPR_TRD.2.1). Доступ к данным другой части предоставляется только по явному запросу (FPR_TRD.2.2). Данные, критичные для невозможности ассоциации (маршрут, время и т.п.), должны храниться в виде, исключающем их полное чтение одной частью сети, чтобы обеспечить невозможность прослеживания всей цепочки между отправителем и получателем сообщения (FPR_TRD.2.3). Этот и два последующих компонента предложены автором профиля защиты; распределение обработки сообщений (FPR_TRD.3). По своей сути этот компонент аналогичен предыдущему с точностью до замены слова "храниться" на "обрабатываться"; невозможность ассоциации пользователей (FPR_UNL.2).


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

Для мер доверия безопасности предлагается оценочный уровень 5. Напомним, что его характерными особенностями являются применение формальной модели политики безопасности, полуформальных функциональной спецификации и проекта верхнего уровня с демонстрацией соответствия между ними, а также проведение анализа скрытых каналов разработчиками и оценщиками. Это очень высокий уровень, но в данном случае его выбор представляется оправданным, поскольку, с одной стороны, объект оценки относительно прост, с легко формализуемой политикой безопасности, а с другой, в функциональных требованиях предусмотрен анализ скрытых каналов.

Рассмотренный профиль защиты, на наш взгляд, весьма поучителен. Он демонстрирует как достоинства, так и недостатки "Общих критериев". К числу достоинств можно отнести богатый набор современных функциональных требований, особо выделив требования приватности. К сожалению, как мы уже отмечали, они носят "точечный", а не концептуальный или архитектурный характер. Для требования распределенности архитектуры пришлось вводить новое семейство - FPR_TRD. Отметим, в свою очередь, что отнесение его к классу приватности не кажется нам оправданным. Распределенность принципиально важна для целого ряда систем, но если в системах электронных платежей, как и в сети серверов пересылки, это необходимое условие приватности (в профиле новое семейство получило наименование "распределения доверия"), то во многих других случаях она играет инфраструктурную роль, обеспечивая живучесть (устойчивость к отказам) и/или масштабируемость (в сочетании с архитектурой менеджер/агент). Очевидно, архитектурные требования заслуживают отдельного класса.

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

Авторы работ [74], [48] справедливо замечают, что введение новых функциональных требований имеет свои оборотные стороны. Конкретные профили получаются проще, естественнее, однако их сравнение с нестандартными компонентами усложняется. Возможный выход подсказывает технология программирования, предусматривающая проблемно-ориентированные расширения базовых интерфейсов, как это выполнено, например, в Java-системах [27]. Подобные расширения можно разработать и стандартизовать быстрее, чем полный набор требований, поскольку они затрагивают более узкий круг специалистов, объединенных к тому же общностью интересов.

Биометрическая идентификация и аутентификация

Системы биометрической идентификации и аутентификации, общие сведения о которых можно найти в курсе [91] "Основы информационной безопасности", весьма актуальны и интересны с точки зрения оценки их безопасности. В данном разделе рассматривается профиль защиты [30], разработанный специалистами Министерства обороны США для оценки коммерческих продуктов, применяемых в среде со средними требованиями к безопасности.

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

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

Вторая угроза - мимикрия под атакуемого субъекта (подражание его голосу, попытки воспроизвести подпись и т.п.). Биометрические данные трудно скрыть, поэтому лучше изначально предполагать, что они общеизвестны, и строить защиту, исходя из этого предположения.

Для компрометации биометрических систем могут применяться искусственные средства идентификации (например, желатиновые муляжи глаз). В контролируемой среде подобным артефактом воспользоваться трудно, однако контроль возможен не всегда.

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

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

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

Возможно использование "остаточных" биометрических данных от предыдущего пользователя, а также воспроизведение подобных данных.

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

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

Выделим ряд специфических функциональных требований:

мониторинг целостности данных функций безопасности (FPT_ITT.3). Требуется обнаружение модификации данных, передаваемых между разделенными частями объекта оценки; при обнаружении ошибки целостности следует уведомить администратора и запротоколировать это событие; противодействие физическому нападению (FPT_PHP.3). Функции безопасности должны противодействовать нарушению физической целостности объекта оценки, а также применению электромагнитных и иных зашумляющих устройств. Для мер доверия выбран четвертый оценочный уровень, что можно считать стандартным (общим) решением.

Межсетевое экранирование

Для межсетевых экранов (МЭ) разработан целый ряд профилей защиты и проектов подобных профилей (см. [43], [60], [59], [23], [24]). Отметим, что экранирование - это, видимо, единственный сервис безопасности, для которого Гостехкомиссия России одной из первых в мире разработала и ввела в действие Руководящий документ [18], его основные идеи получили международное признание и фигурируют в профилях защиты, имеющих официальный статус в таких странах, как США.

Межсетевые экраны классифицируются на основании уровней эталонной семиуровневой модели, на которых осуществляется фильтрация потоков данных. Далее рассматриваются специфические требования двух видов профилей, соответствующих фильтрации на уровнях вплоть до транспортного (пакетная фильтрация) и на всех уровнях, включая прикладной (комплексное экранирование).

Изложение вопросов пакетной фильтрации основывается на профиле [43], наиболее представительном среди документов аналогичного назначения.

В общем случае рассматривается многокомпонентный межсетевой экран. Политика безопасности МЭ базируется на принципе "все, что не разрешено, запрещено".

Информация, поступающая в МЭ, может предназначаться для фильтрации или для изменения параметров самого МЭ. В первом случае идентификация/аутентификация не требуется, во втором она обязательна, причем используются одноразовые пароли (идентифицироваться и аутентифицироваться должны как операторы, осуществляющие удаленное администрирование, так и устройства, в частности маршрутизаторы, посылающие информацию для МЭ, например, измененные таблицы маршрутизации). Для формального описания перечисленных требований применяются компоненты FMT_MSA.1 (управление атрибутами безопасности), FMT_MSA.3 (статическая инициализация атрибутов) и FIA_UAU.5 (сочетание механизмов аутентификации).

Поскольку "Общие критерии" не предназначены для оценки специфических качеств криптографических алгоритмов, рассматриваемый профиль ссылается на федеральный стандарт США FIPS PUB 140-1, требуя согласованности с ним для средств аутентификации, шифрования и контроля целостности.
Формальной оболочкой для данного требования является компонент ОК FCS_COP.1.

Решения по фильтрации потоков данных принимаются на основе набора правил, в которых могут фигурировать исходный и целевой сетевые адреса, протокол транспортного уровня, исходный и целевой порты, а также входной и выходной сетевой интерфейс. Формально ограниченное управление информационными потоками между неаутентифицируемыми сущностями описывается компонентом FDP_IFC.1, а используемые при этом простые атрибуты безопасности - компонентом FDP_IFF.1. Выборочный просмотр регистрационной информации (FAU_SAR.3.1) может основываться на адресах, диапазонах адресов, номерах портов, диапазонах дат и времени.

В плане требований доверия безопасности рассматриваемый профиль ограничивается оценочным уровнем 2. На наш взгляд, этого недостаточно для защиты критически важных систем, функционирующих в среде со средним уровнем риска.

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

Переходя к вопросам комплексного экранирования, отметим, что современные комплексные межсетевые экраны, осуществляющие фильтрацию на всех уровнях, включая прикладной, по сравнению с пакетными фильтрами обеспечивают более надежную защиту, что нашло отражение в дополнительных требованиях безопасности, включенных в профили [59] и [23], [24].

В состав комплексных межсетевых экранов могут входить серверы-посредники, они требуют от пользователей соответствующих сетевых услуг (таких, например, как FTP или Telnet) идентификации и аутентификации (с помощью механизмов, основанных на данных одноразового использования и соответствующих компоненту FIA_UAU.4).

В правилах фильтрации могут фигурировать команды протоколов прикладного уровня и параметры команд.

В проекте профиля [23] предписывается организация полного управления межсетевым доступом (компонент FDP_ACC.2), а также предотвращение угроз доступности (FDP_IFC.2.1).



Важным моментом проекта [23] являются требования анонимности (FPR_ANO.1.1), псевдонимности (FPR_PSE.1) и невозможности ассоциации (FPR_UNL.1.1) межсетевого доступа для сущностей, ассоциированных с защищаемой сетью или самим межсетевым экраном. Эти требования могут быть выполнены на основе использования механизма трансляции адресов и применения серверов-посредников.

Пример проекта [23] показывает, что в российских условиях можно обойти формальные, но не содержательные, проблемы, связанные с криптографией. В любом случае криптографические аппаратные и программные модули необходимо разрабатывать и/или оценивать, даже если само слово "криптография" в профиле защиты отсутствует.

Шифрование и контроль целостности необходимы для организации доверенного канала с целью обеспечения безопасности удаленного администрирования (соответствующие требования были рассмотрены ранее в числе общих для различных сервисов). Для них существуют российские ГОСТы, которыми можно воспользоваться при построении аналогов профилей [43] и [59]. Аутентификация, устойчивая к сетевым угрозам, также обязательна, однако национальный криптографический ГОСТ для нее не принят. Приходится, как это сделано в [23], ограничиваться общими требованиями верификации секретов (FIA_SOS.1) и защищенности от подделки (FIA_UAU.3). Впрочем, в любом случае привлечение национальных (а не международных) стандартов создает проблемы взаимодействия с иностранными партнерами и осложняет взаимное признание сертификатов разными странами.

Ролевое управление доступом

Ролевое управление доступом (Role-Based Access Control, RBAC) представляет собой универсальный каркас, нейтральный по отношению к конкретной дисциплине разграничения доступа и предназначенный в первую очередь для упрощения администрирования ИС с большим числом пользователей и различных ресурсов.

Ниже рассматриваются специфические требования для профиля RBAC [77], [75], основанного на версии 2.0 "Общих критериев".

Разделение обязанностей - существенная и специфичная для ролевого управления доступом цель безопасности. Возможность ее достижения - важное достоинство ролевого доступа.

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

Для ролевого управления доступом характерны следующие функции:

создание и удаление ролей; создание, удаление и модификация атрибутов ролей и отношений между ролями; формирование и поддержка ассоциаций между пользователями и ролями; формирование и поддержка ассоциаций между правами доступа и ролями.

Эти функции обслуживаются тремя классами функциональных требований, на которых мы и остановимся:

ограниченное управление доступом (FDP_ACC.1.1). По крайней мере для части операций субъектов над объектами должно действовать ролевое управление доступом, которое в общем случае может существовать с другими дисциплинами разграничения доступа; управление доступом, основанное на атрибутах безопасности (FDP_ACF.1.1). В число учитываемых атрибутов безопасности следует включить, помимо прочих, присвоенные субъекту роли и права доступа этих ролей; управление данными функций безопасности (FMT_MTD). Только администратор должен иметь возможность определения и изменения ролей, их атрибутов, связей между ними и ограничений на подобные связи (FMT_MTD.1.1). Необходимы и другие требования класса FMT, но они в данном случае носят прямолинейный характер и рассматриваться не будут.

Требования безопасности при сбое (семейство FPT_FLS) имеют технический характер. Должно сохраняться безопасное состояние в ситуациях, когда база данных ролей недоступна или повреждена (FPT_FLS.1.1). Как и в случае управления безопасностью, другие требования этого класса необходимы, но не нуждаются в детальном рассмотрении.

Можно видеть, что функциональные требования "Общих критериев" полезны для достижения тактических целей безопасности. Стратегические цели, носящие концептуальный или архитектурный характер, - организация иерархии ролей с небольшим числом сущностей на каждом уровне или следование принципу разделения обязанностей - приходится формулировать отдельно, без стандартизованной понятийной базы.

Системы активного аудита

В работе [6] приведен набросок семейства профилей защиты для классификации систем активного аудита, а также соображения по расширению набора функциональных требований "Общих критериев". Проекты ПЗ для важнейших компонентов подобных систем - анализатора и сенсора - представлены в [57], [58].

Под подозрительной активностью понимается поведение пользователя или компонента информационной системы - злоумышленное (в соответствии с заранее определенной политикой безопасности) или нетипичное (согласно принятым критериям).

Назначение активного аудита - оперативно выявлять подозрительную активность и предоставлять средства для автоматического реагирования на нее.

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

В число функций безопасности, специфичных для средств активного аудита, входят генерация и извлечение регистрационной информации, ее анализ и реагирование на подозрительную активность.

Отметим, что такой универсальный аспект, как безопасное администрирование, для средств активного аудита приобретает особое значение, если включить в него автоматическую коррекцию (в первую очередь - пополнение) базы сигнатур атак. Тем не менее, соответствующие требования целесообразно отнести к числу общих, поскольку аналогичная возможность нужна, например, другому сервису безопасности - анализу защищенности.

Из существенных для активного аудита компонентов класса FAU "Аудит безопасности" в "Общих критериях" отсутствуют анализ на соответствие политике безопасности (пороговый, статистический и сигнатурный анализы в семействе FAU_SAA предусмотрены), хранилища для описаний контролируемых объектов и для анализируемой информации, а также все интерфейсные компоненты.
Слабо отражена возможность выбора рассматриваемых событий как сенсорами (агентами), так и анализаторами (менеджерами).

С целью адекватного отражения специфики средств активного аудита в [6] предложен ряд добавлений к стандартному набору функциональных требований.

В семейство FAU_GEN (генерация данных аудита безопасности) предлагается включить два новых компонента. FAU_GEN.3 - ассоциирование вызвавшего событие объекта с включением в регистрационные записи имени (идентификатора) этого объекта. На минимальном уровне должны протоколироваться открытие/закрытие объекта (установление/разрыв соединения и т.п.), на базовом - все промежуточные операции. На детальном уровне в регистрационные записи должны входить все операнды операции с объектом.

Компонент FAU_GEN.3 добавлен по двум причинам. Во-первых, должна соблюдаться симметрия между субъектами и объектами. Во-вторых, статистические профили целесообразно строить не для субъектов, а для объектов, но для этого нужно располагать соответствующей информацией.

Еще один предлагаемый компонент - FAU_GEN.4 - предназначен для обеспечения неотказуемости сервиса, пользующегося услугами семейства FAU_GEN, от регистрации события. Вообще говоря, неотказуемость реализуется, даже если не были востребованы коммуникации, поэтому здесь нельзя прибегнуть к классу FCO.

Стандартный компонент FAU_SAR.3 дает возможность осуществлять поиск и сортировку регистрационной информации, задавая в качестве критериев логические выражения. Подобные выражения полезны также для задания фильтров, управляющих работой сенсоров.

Автоматический анализ регистрационной информации с целью выявления подозрительной активности представлен в "Общих критериях" четырьмя компонентами семейства FAU_SAA.

FAU_SAA.1 ориентирован на обнаружение превышения порогов, заданных фиксированным набором правил.

FAU_SAA.2 служит для выявления нетипичной активности путем анализа профилей поведения. В "Общих критериях" предлагаются профили для субъектов, хотя профили объектов могут оказаться предпочтительными.



"Общие критерии" допускают анализ и в реальном времени, и постфактум; поддержку анализа в реальном времени следует рассматривать как важнейшую отличительную особенность средств активного аудита .

FAU_SAA.3 направлен на обнаружение простых атак путем проведения сигнатурного анализа.

FAU_SAA.4 позволяет выявлять сложные, многоэтапные атаки, осуществляемые группой злоумышленников.

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

В [6] вводится еще один компонент, FAU_SAA.5, фиксирующий нарушения политики безопасности. Задавать политики предлагается с помощью предикатов первого порядка.

Что касается автоматического реагирования на подозрительную активность, то "Общие критерии", по сути, ограничились констатацией подобной возможности. В [6] рассматривается более сложная сущность - решатель, который, получив рекомендации от компонентов анализа, определяет, действительно ли имеет место подозрительная активность, и, при необходимости, надлежащим образом реагирует (выбирая форму реакции в зависимости от серьезности выявленных нарушений).

Это значит, что решатель должен уметь:

ранжировать подозрительную активность; реагировать в соответствии с рангом нарушения.

Управление обоими аспектами поручено администратору безопасности.

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

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

Мониторы, организующие оболочки для менеджеров средств активного аудита, должны обладать двумя группами свойств:

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

Первая группа обслуживается семейством FPT_SEP.



Вторая группа свойств поддерживается такими техническими решениями, как программное обеспечение (ПО) промежуточного слоя, кластерные конфигурации и т.д. В плане безопасности целесообразно следовать требованиям FPT_FLS.1 (невозможность перехода в небезопасное состояние в случае сбоя или отказа), а также FPT_RCV.2, FPT_RCV.3, FPT_RCV.4 (надежное восстановление в автоматическом режиме, без потери данных, с точностью до функции безопасности).

Безопасность интерфейсов   монитора (с другими мониторами, сенсорами, администратором безопасности) может обеспечиваться компонентами FPT_ITI.1, FPT_ITI.2 (обнаружение и исправление модификации экспортируемых данных), FPT_ITC.1 (конфиденциальность экспортируемых данных), FPT_ITA.1 (доступность экспортируемых данных).

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

Специфичной для средств активного аудита является возможность получения объяснений от анализаторов и решателей по поводу обнаруженной подозрительной активности. Такие объяснения помогают выбрать адекватный способ реагирования.

При формировании классификационной схемы средств активного аудита в [23] предлагается выделить базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты.

Профили защиты, соответствующие классам защищенности, строятся на основе базового ПЗ и соответствующих комбинаций ФП.

В [23] предлагается зафиксировать профили для следующих разновидностей средств активного аудита:

класс 5 - защита одного информационного сервиса с отслеживанием фиксированного набора характеристик и пороговым анализом (базовый ПЗ); класс 4 - защита однохостовой конфигурации с произвольным набором информационных сервисов, отслеживанием сетевого трафика, системных и прикладных событий, пороговым и простым сигнатурным анализом в реальном масштабе времени; класс 3 - защита сегмента локальной сети от многоэтапных атак при сохранении остальных предположений класса 4; класс 2 - защита произвольной конфигурации с выявлением нетипичного поведения при сохранении остальных предположений класса 3; класс 1 - наложение всех требований с возможностью обеспечения заданного соотношения между ошибками первого и второго рода.



В контексте "Общих критериев" важным и сложным является поднятый в [23] вопрос о целесообразности разработки и применения жестких классификационных схем для сервисов безопасности. С одной стороны, гибкость требований ОК такова, что на их основе можно разработать множество профилей защиты с минимальными требованиями, учитывающими специфику информационных систем и их окружения и позволяющими добиться необходимого уровня безопасности с минимальными затратами. С другой стороны, едва ли не все ИС имеют тенденцию к частым и многочисленным изменениям, способным нарушить истинность сделанных в ПЗ предположений безопасности. Слишком точная подгонка профилей защиты (равно как и характеристик ИС) опасна, у них должен быть запас прочности. В приведенной выше классификации предусмотрено изменение защищаемой конфигурации, поэтому заказчик может выбрать класс "на вырост".

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

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

Можно сделать вывод, что для совокупности профилей защиты целесообразно с самого начала планировать построение иерархии наследования с применением соответствующих функциональных пакетов. Часть узлов в этой иерархии (например, общие требования к сервисам безопасности) могут быть фиктивными в том смысле, что им не соответствуют профили для законченных изделий ИТ, однако они столь же необходимы, как и (обобщенные) интерфейсы в объектно-ориентированных системах.

Требования к принудительному (мандатному) управлению доступом

В данном разделе рассматривается первая редакция проекта [2] Руководящего документа Гостехкомиссии России "Безопасность информационных технологий. Меточная защита. Профиль защиты" (ПЗ МЗ), подготовленная в Центре безопасности информации (см. также [65]). ПЗ МЗ соответствует классу безопасности B1 "Оранжевой книги" [41] или четвертому классу защищенности по классификации Гостехкомиссии России для средств вычислительной техники [17].

Профиль защиты для мандатного (принудительного) управления доступом имеет много общего с рассмотренным в предыдущем разделе профилем ПЗ КД. Некоторые отличия носят очевидный характер; например, включение меток безопасности в записи регистрационного журнала (семейство функциональных требований FAU_GEN), выборочный просмотр аудита на основании меток безопасности (FAU_SAR) или включение данных о допуске (FIA_ATD) в число атрибутов безопасности пользователя. Ни на общих свойствах этих двух профилей, ни на рутинных отличиях мы останавливаться не будем.

Перечислим специфичные для ПЗ МЗ функциональные требования:

экспорт данных пользователя (FDP_ETC). При экспорте назначенных данных пользователя должна осуществляться политика мандатного управления доступом (FDP_ETC.1.1, FDP_ETC.2.1). Непомеченные данные экспортируются без атрибутов безопасности (FDP_ETC.1.2), помеченные - с однозначно ассоциированными атрибутами (FDP_ETC.2.2, FDP_ETC.2.3). Устройства, используемые для экспорта данных без атрибутов безопасности, не могут употребляться для экспорта с атрибутами за исключением ситуации, когда изменение в состоянии устройства выполнено вручную и может быть запротоколировано (FDP_ETC.2.4). Отметим, что в ОК в компоненте FDP_ETC.1 отсутствует элемент, необходимый для назначения правил управления экспортом непомеченных данных; ограниченное управление информационными потоками (FDP_IFC.1). Для назначенных субъектов и объектов и всех операций над этими субъектами и объектами осуществляется политика мандатного управления доступом (FDP_IFC.1.1);

иерархические атрибуты безопасности (FDP_IFF.2). Политика мандатного управления доступом должна основываться на метках безопасности субъектов и объектов (FDP_IFF.2.1). Метка безопасности составляется из иерархического уровня и набора неиерархических категорий. На множестве допустимых меток безопасности должно быть определено отношение частичного порядка с указанными далее свойствами (FDP_IFF.2.7). Метки равны, если совпадают их уровни и наборы категорий. Метка A больше метки B, если уровень A больше уровня B и набор категорий B является подмножеством набора A; если уровень A равен уровню B и набор категорий B является собственным подмножеством набора A. Метки несравнимы, если они не равны и ни одна из меток не больше другой. Для любых двух допустимых меток существует наименьшая верхняя грань, которая больше или равна этим меткам, а также наибольшая нижняя грань, которая не больше обеих меток. Должно поддерживаться по крайней мере 16 уровней и 64 категории. Информационный поток между управляемыми субъектами и объектами посредством управляемой операции разрешен, если метка источника больше или равна метке целевого субъекта или объекта (FDP_IFF.2.2);

импорт данных пользователя (FDP_ITC). Это семейство требований симметрично экспортным требованиям FDP_ETC; управление атрибутами безопасности (FMT_MSA.1). Функции безопасности должны осуществлять политику мандатного управления доступом, чтобы ограничить право модификации меток безопасности, ассоциированных с объектами;

роли безопасности (FMT_SMR.1). В число поддерживаемых должна входить роль, дающая право изменять атрибуты безопасности объектов.

Для требований доверия безопасности рассматриваемый профиль предписывает оценочный уровень 3, усиленный компонентом ADV_SPM.1 (неформальная модель политики безопасности объекта оценки).

Требования к произвольному (дискреционному) управлению доступом

Дальнейшее изложение основано на первой редакции проекта [1] Руководящего документа Гостехкомиссии России "Безопасность информационных технологий. Контролируемый доступ. Профиль защиты" (ПЗ КД), подготовленной в Центре безопасности информации. Его прототип [38], базирующийся на версии 2.0 "Общих критериев", был разработан в 1999 году в Агентстве национальной безопасности США.

В принципе, ПЗ КД соответствует классу безопасности C2 "Оранжевой книги" [41] или пятому классу защищенности по классификации Гостехкомиссии России для средств вычислительной техники [17], однако применение методологии и обширного набора требования безопасности из "Общих критериев" позволило сделать профиль, по сравнению с упомянутыми документами, существенно более детальным и обоснованным.

Из соответствия классу безопасности C2 следует, что в ПЗ КД рассматривается только дискреционное (произвольное) управление доступом. Требования, включенные в профиль, направлены на достижение базового уровня безопасности в условиях невраждебного и хорошо управляемого сообщества пользователей при наличии лишь непреднамеренных угроз.

Из числа частных функциональных требований ПЗ КД выделим наиболее важные:

ассоциация идентификатора пользователя (FAU_GEN.2). Функции безопасности должны ассоциировать каждое потенциально протоколируемое событие с идентификатором пользователя - инициатора этого события (на первый взгляд кажется, что из данного требования есть очевидные исключения, например, неудачные попытки идентификации/аутентификации, однако на этой стадии средства контролируемого доступа еще не используются, а за идентификацию и аутентификацию отвечает другой сервис безопасности); выборочный просмотр аудита (FAU_SAR.3). Необходимо предоставить возможность поиска, сортировки, упорядочения регистрационных данных, основываясь на идентификаторах пользователей и, быть может, других специфицированных атрибутах; управление доступом, основанное на атрибутах безопасности (FDP_ACF.1).
Проводимая политика дискреционного управления доступом должна основываться на таких атрибутах, как идентификатор пользователя и принадлежность к группе (группам), а также атрибутах, ассоциированных с объектами. Последние дают возможность сопоставления разрешенных и запрещенных операций с идентификаторами одного или более пользователей и/или групп, задания разрешенных или запрещенных по умолчанию операций; определение атрибутов пользователя (FIA_ATD.1). Для каждого пользователя должен поддерживаться следующий список атрибутов безопасности: идентификатор пользователя, принадлежность к группе, данные аутентификации, допустимые роли;

верификация секретов (FIA_SOS.1). При однократной попытке использования механизма аутентификации или при неоднократных попытках в течение одной минуты вероятность случайного доступа должна быть меньше 1:1000000. Любая обратная связь при попытках использования механизма аутентификации не должна приводить к превышению указанного уровня вероятности; связывание пользователь-субъект (FIA_USB.1). Функции безопасности должны ассоциировать следующие атрибуты безопасности пользователя с субъектами, действующими от имени этого пользователя: идентификатор пользователя, который ассоциируется с событиями аудита; идентификаторы пользователя, применяемые для осуществления политики дискреционного управления доступом; принадлежность к группам, используемая для осуществления политики дискреционного управления доступом; инициализация статических атрибутов (FMT_MSA.3). Должны обеспечиваться ограничительные подразумеваемые значения для атрибутов безопасности, при помощи которых осуществляется политика дискреционного управления доступом (FMT_MSA.3.1). Должна предоставляться возможность определения альтернативных начальных значений для отмены подразумеваемых значений при создании объектов (FMT_MSA.3.2); отмена (FMT_REV.1). Право отмены атрибутов безопасности, ассоциированных с объектами, необходимо предоставлять только пользователям, уполномоченным на это политикой дискреционного управления доступом (FMT_REV.1.1).

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

Выпуск и управление сертификатами

В документе [66] предлагается упорядоченное семейство из четырех профилей защиты для аппаратно-программных компонентов, реализующих выпуск, аннулирование и управление сертификатами открытых ключей (удовлетворяющими, например, спецификациям X.509) (Certificate Issuing and Management Components, CIMC).

Таким образом, перед нами жесткая классификационная схема , рассчитанная на применение в разнообразных средах. Каждый заказчик, учитывая степень критичности ИС и реальные риски, сам выбирает необходимый уровень защищенности и соответствующий ему профиль. На нижнем (первом) уровне потенциал злоумышленников и риски предполагаются низкими, прежде всего обеспечивается защита от случайных ошибок авторизованных пользователей (например, за счет использования принципа разделения обязанностей). При переходе на более высокие уровни угрозы нарастают, а требования ужесточаются. На верхнем (четвертом) уровне злоумышленниками могут быть и авторизованные пользователи, а требования безопасности оказываются настолько жесткими, что удовлетворить им могут только перспективные изделия ИТ. Это разумный подход, снабжающий ориентирами и заказчиков, и разработчиков.

Объект оценки в профилях из [66] является элементом инфраструктуры открытых ключей и в общем случае включает нижеследующие функциональные компоненты:

центр выпуска и аннулирования сертификатов (именуемый также удостоверяющим центром, УЦ). Это - ядро ОО. Сгенерированная информация помещается в хранилище (см. далее). Между различными УЦ могут существовать отношения доверия; центры приема пользовательских запросов на создание сертификатов или изменение их статуса. Обязательные компоненты объекта оценки, которые верифицируют представленные пользователем данные; серверы, обслуживающие протокол оперативной выдачи статуса сертификатов. Этот компонент может отсутствовать или находиться за пределами ОО; серверы восстановления и/или распространения секретного ключевого материала - дополнительная функция.

Отметим, что хранилище сертификатов и информации об их статусе, обслуживающее запросы приложений, находится вне рамок ОО.

Помимо функциональных, в объект оценки входят инфраструктурные компоненты:



криптографический модуль. Он подписывает сертификаты и списки их аннулирования, при необходимости генерирует криптографические ключи. Требования безопасности, предъявляемые к криптографическим модулям, изложены в федеральном стандарте США FIPS PUB 140-2 [44], заменившем FIPS PUB 140-1 (см. [39]); модуль администрирования; модуль идентификации и аутентификации; модуль ролевого управления доступом; модуль протоколирования и аудита.

Представленная выше логическая компонентная архитектура не обязательно совпадает с физической структурой объекта оценки. В принципе возможна монолитная реализация ОО, объединение/расщепление компонентов и т.д.

Переходя к специфическим функциональным требованиям безопасности для среды, отметим выделение в [66] четырех ролей:

администратор (отвечает за установку, конфигурирование, обслуживание нужд пользователей и т.п.); оператор (выполняет резервное копирование и восстановление); инспектор (ведает запросами и утверждением сертификатов и их статуса); аудитор (анализирует регистрационную информацию).

В соответствии с компонентом FMT_SMR.2 (ограничения на роли безопасности), один пользователь не может выступать более чем в одной из перечисленных выше ролей (FMT_SMR.2.3).

Среда должна обеспечить защиту конфиденциальности данных пользователя при передаче между функциями безопасности (FDP_UCT). Более точно, надо обеспечить базовую конфиденциальность обмена данными (FDP_UCT.1). Аналогичная защита необходима для конфиденциальных данных самой среды (FPT_ITC.1, FPT_ITT.1). Кроме того, требуется контроль целостности данных.

Криптографическими методами контролируется целостность (в частности, аутентичность) программного кода, присутствующего в системе, и кода, который в принципе может быть загружен (дополнительные требования профиля FPT_TST_CIMC.2 и FPT_TST_CIMC.3).

Среди специфических (более того, дополнительных, по сравнению с "Общими критериями") функциональных требований безопасности для объекта оценки выделим наиболее значимые:



инициирование и обработка события подписывания регистрационного журнала (FPT_CIMC_TSP.1), выполняемого с конфигурируемой периодичностью. Подпись должна контролировать целостность по крайней мере тех регистрационных записей, которые появились после предыдущего подписывания. В регистрационной записи о самом событии подписывания присутствуют электронная цифровая подпись, значение хэш-функции или имитовставка аналогичного назначения; инициирование и обработка события постановки третьей стороной подписанных меток времени (FPT_CIMC_TSP.2). Этот компонент аналогичен предыдущему и обеспечивает дополнительный контроль целостности регистрационных данных (например, на случай компрометации объекта оценки); резервное копирование и восстановление (FDP_CIMC_BKP.1), с дополнительными (криптографическими) мерами контроля целостности и обеспечения конфиденциальности (FDP_CIMC_BKP.2), с точностью до последней завершенной транзакции (FDP_CIMC_BKP.3). Названные компоненты направлены на безопасное (в том числе свободное от внедрения вредоносного кода) восстановление. Отметим, что подобные требования полезны также для СУБД и других систем с транзакциями; принудительные доказательство и верификация подлинности источника данных о статусе сертификатов и других данных, критичных для безопасности (FCO_NRO_CIMC.3). Аналогично должны контролироваться заявки на регистрацию сертификатов. Предпочтительный способ доказательства подлинности - цифровые подписи (FCO_NRO_CIMC.4).; экспортируемая информация об изменении статуса сертификатов должна иметь формат, описанный в спецификациях X.509 для списков аннулирования или RFC 2560 для протокола оперативной выдачи статуса сертификатов (FDP_CIMC_CSE.1); защита конфиденциальности секретных ключей пользователей (FDP_ACF_CIMC.2) и функций безопасности (FMT_MTD_CIMC.4). Секретные ключи обслуживающего персонала и функций безопасности объекта оценки должны храниться в стандартном криптографическом модуле или шифроваться стандартными методами. Секретные ключи пользователей шифруются с помощью долговременных ключей защиты.


Аналогичные требования предъявляются к хранению секретных ключей симметричных методов шифрования (FDP_ACF_CIMC.3 и FMT_MTD_CIMC.5); секретные ключи должны экспортироваться либо в зашифрованном виде, либо с использованием процедур разделения знаний (FDP_ETC_CIMC.4, FDP_ETC_CIMC.5, FMT_MTD_CIMC.6, FMT_MTD_CIMC.7); контроль целостности хранимых открытых ключей (FDP_DSI_CIMC.3). Открытые ключи, хранимые в объекте оценки вне криптографического модуля, нужно защитить от несанкционированного изменения стандартными криптографическими методами. Проверку целостности требуется производить при каждом доступе к ключу; обнуление секретных ключей (FCS_CKM_CIMC.5). Функции безопасности должны обеспечить обнуление открытого представления секретных ключей в криптографическом модуле; контроль допустимости значений полей сертификатов (FMT_MOF_CIMC.3). Функции безопасности контролируют значения полей сертификатов в соответствии с правилами, заданными администратором. Аналогичные проверки необходимо производить для списков аннулированных сертификатов (FMT_MOF_CIMC.5) и сообщений протокола оперативной выдачи статуса сертификатов (FMT_MOF_CIMC.6); генерация сертификатов (FDP_CIMC_CER.1). Генерируются только корректные сертификаты, удовлетворяющие требованиям стандарта (X.509) и правилам, заданным администратором. Такие же требования должны выполняться для списков аннулированных сертификатов (FDP_CIMC_CRL.1) и сообщений протокола оперативной выдачи статуса сертификатов (FDP_CIMC_OCSP.1). До выпуска сертификата необходимо убедиться, что его предполагаемый владелец обладает секретным ключом, ассоциированным с открытым ключом из сертификата.

Требования доверия безопасности усиливаются параллельно с возрастанием выбранного уровня профиля защиты. Для верхнего, четвертого уровня используются в основном требования ОУД4 и, частично, ОУД5, а также требование ALC_FLR.3 (систематическое устранение недостатков), не входящее ни в один ОУД.

На наш взгляд, рассмотренное семейство профилей может служить примером при построении классификационных схем в Руководящих документах Гостехкомиссии России.

Некоторые выводы

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

В то же время, сама гибкость "Общих критериев" - источник сложных проблем, в первую очередь относящихся к методологии разработки   профилей защиты. Можно провести аналогию с языками и технологией программирования, когда владение передовым языком программирования вовсе не означает умения проектировать и создавать большие программные комплексы.

Вопросы технологии "программирования" профилей защиты носят разнообразный характер и затрагивают все этапы жизненного цикла ПЗ. Какой подход выбрать при разработке ПЗ: "снизу вверх" или "сверху вниз"? Сами "Общие критерии", имеющие библиотечную (не объектную) структуру, подталкивают к применению подхода "снизу вверх", от отдельных требований к общей функциональности. Однако, как показывает опыт разработчиков профиля [48] (равно как и технология программирования), наиболее предпочтителен подход "сверху вниз", от требуемой функциональности объекта оценки к базовым механизмам безопасности.

Еще один технологический аспект - модульность ПЗ. Выделение функциональных пакетов для составных частей объекта оценки, реализованное в [80], дает больше свободы и разработчикам, и интеграторам, способствует раннему выявлению и устранению проблем, облегчает деятельность оценщиков.

Следующий вопрос касается технологии сопровождения множества профилей защиты. Как соотносить между собой отдельные ПЗ? Как группировать их, выстраивать иерархии и т.п.? Пока зарегистрированных профилей относительно немного (что само по себе является проблемой, но, можно надеяться, временной), и все-таки очевидно, что их число будет расти, они станут поступать из различных источников, из разных стран, так что поддержание международного статуса "Общих критериев", несомненно, потребует специальных усилий, которые целесообразно планировать заранее (см. соглашение "О признании сертификатов по Общим критериям в области безопасности информационных технологий").

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

Принципиальный недостаток - отсутствие в "Общих критериях" архитектурных и технологических требований. Такие свойства, как распределенность архитектуры, следование подходу менеджер/агент и т.п., необходимы для успешной реализации функций объекта оценки, они критичны для его безопасности.

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

создание новых профилей защиты, охватывающих все сервисы безопасности;разработка методологии и соответствующих инструментальных средств создания ПЗ;разработка дисциплины и инструментальных средств для использования множества профилей защиты;развитие "Общих критериев", разработка новых стандартных требований безопасности, как "точечных", так и концептуальных, архитектурных;разработка дисциплины введения новых нестандартных требований с минимизацией проблем несопоставимости получающихся профилей защиты.

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

<

Операционные системы

Операционные системы (ОС) - классический объект оценки по требованиям безопасности еще со времен "Оранжевой книги". Более того, до сих пор остается весьма распространенным мнение о том, что это важнейшее, едва ли не единственное защитное средство. С современных позиций ОС можно рассматривать как комбинацию сервисов идентификации и аутентификации, управления доступом и протоколирования/аудита. Кроме того, операционные системы обеспечивают базовые, инфраструктурные свойства безопасности, в том числе разделение доменов и посредничество при обращениях.

Для операционных систем разработан целый ряд профилей защиты (см. [72], [73], [83], [84], [3], [4]). К этой же группе документов можно отнести руководство по разработке профилей для перспективных коммерческих продуктов ИТ [82], поскольку оно, как и [73], [83], [84], [4]), ориентировано на класс безопасности C2 "Оранжевой книги".

Мы, однако, рассмотрим проект [3]

(адаптированный вариант профиля [72]) , в целом соответствующий четвертому классу защищенности по классификации Гостехкомиссии России для средств вычислительной техники, поскольку он более представителен с точки зрения требований безопасности.

Операционные системы, удовлетворяющие проекту ПЗ, должны обеспечивать дискреционное и мандатное управление доступом, мандатное управление целостностью и предоставлять криптографические сервисы . Всем пользователям необходим ассоциированный уровень допуска, определяющий максимальный уровень чувствительности данных, к которым они могут обращаться (см. выше раздел "Требования к принудительному (мандатному) управлению доступом").

Вероятно, единственная специфическая угроза для рассматриваемого класса ОС заключается в неадекватной классификации данных на основе их меток, что способствует осуществлению несанкционированного доступа к (помеченным) данным. В качестве контрмеры провозглашается специфическая цель безопасности: "Операционная система должна предоставлять возможность расставлять точные метки чувствительности и целостности".

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

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

Из числа специфических функциональных требований наибольший интерес представляют криптографические компоненты. Остановимся на них подробнее:

генерация криптографических ключей (FCS_CKM.1). Симметричные криптографические ключи должны генерироваться в соответствии с согласованным с ФАПСИ алгоритмом, реализуемым аппаратным или программным генератором случайных чисел (см. далее компонент FCS_COP_EXP.2) и/или схемой генерации ключей, которая основана на криптографии с открытым ключом, использует программный и/или аппаратный генератор случайных чисел, определенный в FCS_COP_EXP.2, и хэш-функцию по ГОСТ Р 34.11-94. Асимметричные криптографические ключи должны генерироваться, согласуясь с параметрами криптографического преобразования, применяя генератор случайного числа и/или генератор простых чисел и удовлетворяя ГОСТ Р 34.10-2001 в части генерации простых чисел, ГОСТ Р 34.10-2001 для реализации процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма, ГОСТ 28147-89 для реализации процедур зашифрования и расшифрования данных, а также требованиям из этого проекта ПЗ: FPT_CTST_EXP, FCS_COP_EXP.2

и документации разработчика. Дополнительное требование упомянутого проекта ПЗ состоит в том, что к каждому сгенерированному симметричному ключу должна добавляться имитовставка алгоритма ГОСТ 28147-89 или контрольная сумма другого аттестованного алгоритма (FCS_CKM_EXP.1);распределение криптографических ключей (FCS_CKM.2). Согласно проекту профиля [3], ключи должны распределяться (вручную или автоматически) в соответствии с требованиями ФАПСИ и действующих нормативных документов.


Не предусматривается автоматическое распределение секретных ключей асимметричных криптосистем;доступ к криптографическим ключам (FCS_CKM.3). Ключи должны храниться только в зашифрованном виде в соответствии с требованиями ФАПСИ и действующих нормативных документов (FCS_CKM.3.1). Дополнительное требование: информацию, позволяющую однозначно идентифицировать ключ (FCS_CKM_EXP.3.1), хранить нельзя;уничтожение криптографических ключей (FCS_CKM.4). Криптографические ключи должны уничтожаться в соответствии с требованиями ФАПСИ и действующих нормативных документов. Удалять ключи и другие критичные параметры необходимо немедленно, полностью и таким образом, чтобы поверх ключа/критичной области памяти записывались три или более различных шаблонов (FCS_CKM.4.1);криптографические операции (FCS_COP.1). Операции зашифрования/расшифрования данных должны выполняться в соответствии с алгоритмом криптографического преобразования по ГОСТ 28147-89 или другим аттестованным алгоритмом, а операции вычисления цифровой подписи - в соответствии с алгоритмом выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма по ГОСТ Р 34.10-2001 или другим аттестованным алгоритмом. Операции хэширования выполняются согласно определенному ГОСТ Р 34.11-94 или другому аттестованному алгоритму, операции обмена криптографическими ключами - в соответствии с требованиями ФАПСИ и действующих нормативных документов. (FCS_COP.1.1);генерация случайных чисел (FCS_COP_EXP.2 - дополнительный компонент, предложенный в данном проекте ПЗ). Генерация случайных чисел должна выполняться множеством независимых аппаратных и/или программных датчиков, выходы которых объединяются с использованием хэш-функции по ГОСТ Р 34.11-94 или другого аттестованного алгоритма (FCS_COP_EXP.2.1). Датчики случайных/псевдослучайных чисел необходимо защитить от нарушения алгоритмов (режимов) их функционирования (FCS_COP_EXP.2.2);защита остаточной информации криптографического ключа (FDP_RIP_EXP.2 - дополнительный компонент).


Любой ресурс, содержащий критичные параметры безопасности, при освобождении этого ресурса должен быть очищен от всей информации путем перезаписи поверх его содержимого, как определено процедурой уничтожения ключа;отделение домена функций безопасности (FPT_SEP_EXP.1 - дополнительный компонент). Поддерживается криптографический домен, отделенный от остальных функций безопасности, защищенный от вмешательства и искажения недоверенными субъектами (FPT_SEP_EXP.1.1);тестирование криптографического модуля (FPT_CTST_EXP - дополнительное семейство). Для проверки правильности функционирования криптографического модуля необходимо реализовывать возможность его тестирования путем выполнения набора встроенных тестов при начальном запуске, по запросу администратора по криптографии и периодически (FPT_CTST_EXP.1.1). Тесты должны обеспечивать проверку и документирование статистических характеристик генераторов случайных/псевдослучайных чисел и отображение результатов тестирования (FPT_CTST_EXP.1.2). Предписывается выполнение тестов обнаружения ошибок в ключе при начальном запуске и по запросу администратора по криптографии (FPT_CTST_EXP.1.3), а также немедленное (сразу после генерации ключа) самотестирование каждого участвующего в генерации ключей компонента для верификации его функционирования в соответствии с FCS_CKM.1.1 и FCS_COP_EXP.2 (FPT_CTST_EXP.1.4). Сгенерированный ключ не должен использоваться, если самотестирование какого-либо компонента завершилось неудачей (FPT_CTST_EXP.1.5);доверенный маршрут (FTP_TRP_EXP.1 - дополнительный компонент). Криптографический модуль должен обеспечивать маршрут связи между собой и локальными пользователями, который логически отличим от других маршрутов и предоставляет уверенную идентификацию самого себя (FTP_TRP_EXP.1.1).

Для обслуживания криптографических средств в рассматриваемом проекте ПЗ предусмотрен дополнительный компонент требований доверия безопасности:

анализ скрытых каналов криптографического модуля (AVA_CCA_EXP.1). Для криптографического модуля разработчику следует провести поиск скрытых каналов утечки критичных параметров безопасности (AVA_CCA_EXP.1.1D) и представить документацию анализа скрытых каналов (AVA_CCA_EXP.1.2D), которая идентифицирует скрытые каналы в криптографическом модуле и содержит оценку их пропускной способности (AVA_CCA_EXP.1.1C).


Документация должна содержать описание процедур, используемых для заключения о существовании скрытых каналов в криптографическом модуле, и информацию, необходимую для проведения анализа скрытых каналов (AVA_CCA_EXP.1.2C). Кроме того, в ней описываются все предположения, сделанные в процессе анализа (AVA_CCA_EXP.1.3C), метод, применяемый для оценки пропускной способности канала в случае наиболее опасного сценария (AVA_CCA_EXP.1.4C), и сам наиболее опасный сценарий использования каждого идентифицированного скрытого канала (AVA_CCA_EXP.1.5C). Оценщик обязан подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств (AVA_CCA_EXP.1.1E), а результаты анализа скрытых каналов показывают, что криптографический модуль удовлетворяет функциональным требованиям (AVA_CCA_EXP.1.2E). Наконец, произведя тестирование, он выборочно подтверждает правильность результатов анализа скрытых каналов (AVA_CCA_EXP.1.3E).

Можно видеть, что в проекте профиля [3]

вопросы криптографии изложены весьма пространно, однако смысл всех требований предельно прост: соответствие национальным стандартам (их три). Многократно упоминаемое соответствие требованиям ФАПСИ и действующих нормативных документов - условие туманное, допускающее неоднозначное толкование. (Заметим, что ссылка на требования определенного ведомства - вещь рискованная, так как последнее может прекратить свое существование.) Небесспорно и введение дополнительных, по сравнению с "Общими критериями", требований (функциональных и доверия).

Напомним, что в рассмотренном выше ПЗ для межсетевых экранов [43]

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


Целесообразно выделить требования к криптографическим модулям в отдельный документ, как это сделано в федеральном стандарте США FIPS PUB 140-2 [44], а не перегружать ими профиль защиты ОС.

Далее, в рассматриваемом проекте ПЗ предусмотрена возможность удаленного администрирования, но отсутствует упоминание об аутентификации с использованием криптографических методов, а также о защите от подделки и/или воспроизведения аутентификационных данных (компоненты FIA_UAU.3 и FIA_UAU.4 "Общих критериев"). В результате остаются без противодействия стандартные сетевые угрозы.

Еще одна специфическая особенность ОС - возможность управления использованием ресурсов, их распределением между пользователями. Для этого уместно применить механизм квотирования.

максимальные квоты (FRU_RSA.1). Пользователям должны выделяться квоты долговременной и оперативной памяти, а также процессорного времени (FRU_RSA.1.1).

Рассмотренный проект профиля защиты для операционных систем показывает, как важно соблюдать определенный уровень формализации изложения, а также единый уровень детализации. Неоднородность ПЗ чревата несистематичностью, завышением или занижением требований. К сожалению, "Общие критерии" не регламентируют этот аспект разработки профилей защиты, заданий по безопасности и функциональных пакетов.

Отдельного рассмотрения заслуживают специфические функциональные требования, присутствующие в проекте [83]. Выше, в разделе "Системы активного аудита", мы отмечали важность требований к интерфейсам и их безопасности. В [83] предложен дополнительный элемент FAU_GEN.1-CSPP.3, предписывающий предоставление прикладного программного интерфейса для добавления собственных данных к общему регистрационному журналу и/или для ведения приложениями собственных журналов.

Для управления экспортом данных пользователя в соответствии с политикой безопасности введен элемент FDP_ETC.1-CSPP.3, предусматривающий выделение отдельного пула выходных каналов (например, путем резервирования номеров TCP-портов), недоступных обычным приложениям.

Поддержка распределенных конфигураций регламентируется целым рядом дополнительных требований, направленных на обеспечение конфиденциальности (FPT_ITC.1.1-CSPP), целостности (FPT_ITI.1.1-CSPP), согласованности (FPT_SYN-CSPP.1.1) критичных данных функций безопасности.

В заключение раздела следует отметить, что в Центре безопасности информации создан проект базового профиля защиты для ОС и разрабатывается профиль защиты ОС в средах, нуждающихся в высокой робастности (защищенности), с тем чтобы иметь завершенное семейство профилей защиты   операционных систем.

Системы управления базами данных

Системы управления базами данных (СУБД), как и операционные системы, содержат комбинацию сервисов безопасности, однако, в отличие от ОС, не являются самодостаточными. СУБД используют механизмы и функции ОС. Такая двухуровневость ведет к появлению специфических угроз и требует привлечения соответствующих средств противодействия. Например, базы данных располагаются в файлах или на дисках, управляемых ОС; следовательно, к объектам БД можно обратиться как штатными средствами СУБД , так и с помощью механизмов ОС, получив доступ к файлу или устройству. Подобные возможности должны учитываться в профиле защиты для СУБД.

Дальнейшее изложение основано на проекте ПЗ [5] (его прототип [81] соответствует классу безопасности C2 "Оранжевой книги").

Здесь вводится понятие аутентификационного пакета, который предоставляет для СУБД механизм подтверждения подлинности заявляемого идентификатора пользователя. В рассматриваемом проекте профиля защиты для этого необходим хотя бы один из двух механизмов: внешний (аутентификация средствами ОС) или внутренний (аутентификация средствами СУБД).

Еще одно проявление упомянутой выше двухуровневости - предположение безопасности базовой конфигурации, состоящее в том, что базовая система (операционная система, и/или сетевые сервисы безопасности, и/или специальное программное обеспечение) установлены, сконфигурированы и управляются безопасным образом. Аналогичную направленность имеют цели безопасности для среды, предусматривающие, что базовая система должна обеспечить механизмы управления доступом, которые позволят защитить от несанкционированного доступа все связанные с СУБД файлы; кроме того, ОС предоставит средства для изоляции функций безопасности и защиты процессов СУБД.

Отметим, что в распределенной среде управление доступом и изоляция могут поддерживаться не только средствами базовой ОС, но и архитектурно, путем разнесения компонентов СУБД по узлам сети и использования межсетевых экранов. Эта возможность в проекте [5] не рассматривается.

Переходя к функциональным требованиям безопасности, укажем на важность требований согласованности данных между функциями безопасности (FPT_TDC), а также согласованности данных функций безопасности при дублировании в пределах распределенного объекта оценки (FPT_TRC). Согласованность достигается с помощью некоторой формы обработки распределенных транзакций или путем обновления дублируемых данных с применением какого-либо протокола синхронизации. К сожалению, требования этих семейств в проекте [5] не представлены, равно как и требования распределенности хранения и обработки для повышения устойчивости к отказам. Конечно, в "Оранжевой книге" ничего подобного не было, однако в наше время, как показывает профиль [48], следование определенным архитектурным принципам является обязательным.

Для защиты от атак на доступность в рассматриваемом проекте предусмотрены реализация квот, выделяемых пользователям (FRU_RSA.1), а также базовые ограничения на параллельные сеансы (FTA_MCS.1).

В целом, на наш взгляд, проект [5] нуждается в доработке. Необходимо учесть специфику современных СУБД, в частности, требования обеспечения динамической целостности данных, реализуемые механизмом транзакций. Требования безопасного восстановления носят слишком общий характер. Защита от стандартных угроз, существующих в сетевой среде, целиком переложена на базовую систему. Не учтены специфические для СУБД угрозы, описанные, например, в главе "Информационная безопасность систем управления базами данных" книги [86].

Смарт-карты

Профиль защиты для смарт-карт [80] интересен необычностью объекта оценки. Он позволяет оценить гибкость и разнообразие требований "Общих критериев".

Эта необычность заключается в следующем:

минимум аппаратных ресурсов (интегральная схема, включающая процессор; оперативная и постоянная память относительно небольшого объема; порты ввода/вывода) в сочетании с программным обеспечением ограниченной функциональности (в профиле [80] рассматривается базовое ПО);принадлежность неконтролируемой среде, когда карта может оказаться в руках злоумышленника, располагающего специальным оборудованием.

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

Отметим, что приемное устройство, снабжающее смарт-карту электропитанием и связью с внешним миром, не входит в объект оценки.

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

Сформулируем предположения безопасности для среды:

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

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

осуществление доступа к смарт-карте с помощью специального оборудования, когда преследуется цель выяснить определенные аппаратные и/или программные характеристики (применяемые криптографические механизмы, используемые ключи, хранимые данные и программы и т.п.). Не исключены попытки изменить аппаратно-программную конфигурацию и/или данные, а также перевести смарт-карту в небезопасное состояние, поместив ее в стрессовые условия (например, температурные или электромагнитные);логические атаки: отслеживание зависимостей между входными данными операций, выполняемых смарт-картой, и результатами; попытки перевести карту в небезопасное состояние искусственно инициированным сбросом или загрузить вредоносные программы; использование некорректных входных данных; воспроизведение данных аутентификации; переборные атаки (на криптографические компоненты).
К этой же категории угроз можно отнести попытки организовать нештатное взаимодействие прикладных функций и выполнить действия (например, отладочные), предусмотренные для особых этапов жизненного цикла смарт-карты. Одновременное проведение нескольких атак;несанкционированный доступ: попытки злоупотребления полномочиями при доступе к пользовательским данным или данным функций безопасности, а также использования новой, не до конца оформленной смарт-карты;попытки выявления и анализа утечек информации во время нормальной работы смарт-карты, совместный анализ результатов многих наблюдений.попытки изготовления копий (клонирование) компонентов смарт-карты для детального изучения их поведения.

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

Из специфических положений политики безопасности прежде всего отметим наличие уникальных идентификационных данных для каждого объекта оценки, а также (как ни странно) накопление регистрационной информации, которое необходимо производить, несмотря на ограниченность ресурсов. Аудит может выполняться во время сервисного обслуживания смарт-карты.

Цели безопасности формулируются таким образом, чтобы обеспечить нейтрализацию угроз и выполнить положения политики безопасности: интегральная схема должна работать в любых, в том числе стрессовых, условиях; осуществляется защита от многократного использования ресурсов при переборных атаках; изучение передаваемых данных не должно давать дополнительной информации по сравнению с анализом содержимого памяти; нормальное (безопасное) состояние устанавливается сразу после подачи питания или сброса; при замене интегральной схемы на карте обязательно должны оставаться следы и т.п.

Перейдем к рассмотрению специфических функциональных требований:

автоматическая реакция аудита безопасности (FAU_ARP) при обнаружении возможного нарушения безопасности. Предписываются минимальные необратимые последствия реакции.


Подчеркнем, что в силу специфики объекта оценки оперативное информирование администратора безопасности в общем случае невозможно; с опасностью приходится бороться самостоятельно;генерация списка регистрационных данных (FAU_LST - дополнительное семейство). На интегральной схеме, устанавливаемой в смарт-карте, нет часов; время указывает только приемное устройство, которое не считается доверенным. Следовательно, события можно лишь упорядочить по мере их появления, но с ними нельзя ассоциировать дату и время. В регистрационную информацию должны включаться идентификационные данные аппаратных и программных компонентов;противодействие физическому нападению (FPT_PHP.3). Функции безопасности обязаны противодействовать попыткам эксплуатации в стрессовых условиях, отслеживанию информации, другим физическим атакам, автоматически реагируя таким образом, чтобы предотвратить нарушение политики безопасности (FPT_PHP.3.1);надежное восстановление (FPT_RCV). Автоматическое восстановление без недопустимой потери (FPT_RCV.3), восстановление функции (FPT_RCV.4).

Для требований доверия безопасности в [80] используется усиленный оценочный уровень 4. Усиление обеспечивают компоненты AVA_VLA.3 (систематический поиск уязвимостей, обеспечение стойкости к нападениям, выполняемым нарушителем с умеренным потенциалом) и ADV_INT.1 (модульность).

Важным достоинством работы [80] является выделение двух функциональных пакетов: для интегральной схемы и базового ПО. Эти части могут разрабатываться независимыми производителями, поэтому целесообразно, чтобы они проводили такую же независимую сертификацию, а интегратор (производитель смарт-карт) выбирал поставщиков и осуществлял интегральную сертификацию. В части функциональных требований пакет для базового ПО аналогичен рассмотренному профилю; к аппаратуре предъявляется меньшее число требований. Например, в функциональном пакете для интегральной схемы отсутствуют компоненты FAU_SAA.1 (анализ потенциального нарушения) и FPT_RPL.1 (обнаружение повторного использования), что представляется вполне естественным.

Виртуальные частные сети

Туннелирование и шифрование (наряду с необходимой криптографической инфраструктурой) на выделенных шлюзах в комбинации с экранированием на маршрутизаторах поставщиков сетевых услуг (для разделения пространств "своих" и "чужих" сетевых адресов в духе виртуальных локальных сетей) позволяют реализовать такое важное в нынешних условиях защитное средство, как виртуальные частные сети. Подобные сети, наложенные обычно поверх Internet, существенно дешевле и гораздо безопаснее, чем действительно собственные сети организации, построенные на выделенных каналах. Коммуникации на всем их протяжении физически защитить невозможно, поэтому лучше изначально исходить из предположения об уязвимости и соответствующим образом обеспечивать защиту. Современные протоколы, поддерживающие спецификации IPsec (см., например, [9]), позволяют сделать это.

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

В качестве основы последующего изложения выбран проект профиля защиты [26], где объект оценки - совокупность опорных узлов. Требования к перспективным средствам аналогичного назначения представлены в документе [79].

Поскольку реализация виртуальных частных сетей в значительной степени основывается на криптографических механизмах, в число специфических угроз входят применение злоумышленником методов и средств криптографического анализа, а также компрометация криптографических ключей. Упомянем и угрозы доступности каналов связи.

Для нейтрализации угроз должны быть выполнены функциональные требования безопасности, относящиеся к криптографии.
Необходимо осуществление контроля доступа к криптографическим ключам (FCS_CKM.3.1), шифрование (FCS_COP.1.1) и применение механизмов контроля целостности (FCS_COP.1.1) информации, передаваемой в рамках доверенного канала.

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

От виртуальных частных сетей требуется реализация некоторых аспектов приватности. Они не должны допустить, чтобы извне можно было определить подлинное имя пользователя, связанного с передаваемой в рамках доверенного канала информацией (FPR_ANO.1.1). В то же время, администратору необходимо предоставить возможность наблюдения за использованием ресурсов и функционированием процессов (FPR_UNO.4.1).

Опорные узлы должны обладать определенной отказоустойчивостью, обеспечивая возврат к безопасному состоянию, генерацию записи журнала аудита, сигнализацию администратору, когда происходит сбой в системе электропитания или нарушение безопасности (FRU_FLT.1.1).

Таковы специфические функциональные требования безопасности для виртуальных частных сетей. В "Общих критериях" в явном виде не представлены требования к туннелированию; нет их и в рассмотренном проекте. Возможно, туннелирование трактуется лишь как механизм обеспечения анонимности.

Виртуальные локальные сети

Под виртуальной локальной сетью в проекте профиля защиты [25] понимается такое логическое объединение узлов локальной сети, при котором обмен данными на канальном уровне эталонной семиуровневой модели возможен только между этими узлами.

Использование виртуальных локальных сетей позволяет:

повысить производительность (и доступность) сети за счет локализации потоков данных;обеспечить защиту передаваемых данных посредством логического разделения среды передачи;реализовать управление доступом пользователей к сетевым ресурсам.

Разграничение потоков данных обеспечивается путем фильтрации кадров данных. Таким образом, объект оценки оказывается межсетевым экраном канального уровня.

В проекте [25] рассматриваются два способа построения виртуальных локальных сетей:

группировка портов объекта оценки. В этом случае каждый порт поддерживает только одну виртуальную сеть;использование специальной метрики для определения принадлежности к конкретной виртуальной локальной сети.

Впрочем, предлагаемые в проекте требования безопасности в равной степени применимы к обоим вариантам.

От рассмотренных ранее межсетевых экранов объект оценки отличается ограниченностью ресурсов и меньшей функциональностью. В частности, вся работа с регистрационной информацией (начиная с хранения) возлагается на среду, точнее, на так называемое средство анализа событий. Это освобождает объект оценки от ряда стандартных требований протоколирования и аудита, но ведет к необходимости организации доверенного канала.

Каркас сертификатов атрибутов

Вероятно, развитие механизма расширений натолкнуло авторов рекомендаций X.509 на мысль о том, что в заверенных сертификатах можно хранить не только открытые ключи, но и произвольные атрибуты субъектов - держателей (владельцев) сертификатов.

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

Вообще говоря, сертификаты атрибутов имеют универсальный характер, но в рекомендациях X.509 внимание акцентируется на их применении в качестве основы инфраструктуры управления привилегиями.

У каркасов сертификатов открытых ключей и сертификатов атрибутов немало общего. Это и система удостоверяющих центров, и списки отзыва, и многое другое. Мы, однако, сосредоточимся на специфике управления привилегиями.

Отметим в первую очередь, что жизненные циклы открытых ключей и привилегий устроены по-разному, имеют разную длительность. Привилегии могут делегироваться вспомогательным сущностям на короткие промежутки времени (порядка минуты). Для управления привилегиями используются свои понятия и механизмы, например роли. Следовательно, хотя с синтаксической точки зрения для цели управления привилегиями можно использовать снабженные соответствующими расширениями сертификаты открытых ключей, идейная и практическая сторона вопроса подразумевает разделение каркасов открытых ключей и управления привилегиями, что и сделано в рекомендациях X.509.

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

На протяжении маршрута делегирования должно действовать правило доминирования: промежуточный центр авторизации не вправе делегировать больше привилегий, чем сам имеет (для каждой привилегии должно быть определено, что значит "не больше").

Вообще говоря, известны две схемы выделения и проверки привилегий:

удостоверяющий центр по собственной инициативе наделяет некоторую сущность привилегиями, создав сертификат атрибутов и поместив его в Директорию с предоставлением свободного доступа. В дальнейшем верификатору привилегий разрешается использовать этот сертификат при принятии решения о предоставлении определенного вида доступа. Перечисленные действия могут происходить без ведома и участия субъекта - держателя сертификата;субъект запрашивает центр авторизации на предмет получения определенной привилегии. При положительном решении созданный сертификат атрибутов возвращается держателю и явным образом предъявляется последним при доступе к защищенным ресурсам.

Независимо от принятой схемы выделяются три основных понятия инфраструктуры управления привилегиями:



объект (точнее, метод объекта), к которому осуществляется доступ и который может быть снабжен такими атрибутами, как метка безопасности.

предъявитель привилегий;

верификатор привилегий, принимающий решения (с учетом действующей политики безопасности и существующего окружения) о достаточности предъявленных привилегий для предоставления доступа.

Верификатор привилегий - это какая-либо экранирующая сущность, логически располагающаяся между вызывающим и вызываемым методами объектов; рекомендации X.509 не налагают ограничений на правила экранирования.

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

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

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

Каркас сертификатов открытых ключей

Мы приступаем к изучению четвертой редакции рекомендаций X.509 [51], которая регламентирует следующие аспекты:

сертификаты открытых ключей;сертификаты атрибутов;сервисы аутентификации.

Идейной основой рекомендаций X.509 являются сертификаты открытых ключей, обслуживающие такие грани информационной безопасности, как конфиденциальность и целостность, и такие сервисы, как аутентификация и неотказуемость.

В курсе "Основы информационной безопасности" [91] приведены необходимые сведения о криптографии с открытыми ключами и механизме электронной цифровой подписи (ЭЦП); далее предполагается, что они уже известны.

Сертификат открытого ключа - это структура данных, обеспечивающая ассоциирование открытого ключа и его владельца. Надежность ассоциации, подлинность сертификата подтверждаются подписью удостоверяющего центра (УЦ).

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

Формат сертификата описан в курсе [91]. В простейшем случае он выглядит так:

CA <<A>> = CA {V, SN, AI, CA, A, Ap, TA}

Здесь:

A - имя владельца сертификата;CA - имя удостоверяющего центра;CA <<A>> - сертификат, выданный A центром CA;CA {I} - данные I, снабженные подписью CA;V - версия сертификата (в настоящее время - версия 3);SN - порядковый номер сертификата;AI - идентификатор алгоритма, использованного при подписании сертификата;Ap - информация об открытом ключе A;TA - даты начала и конца срока годности сертификата.

Отметим, что в общем случае формат может быть существенно сложнее. С помощью механизма расширений его можно приспособить для нужд различных приложений и сообществ пользователей. В X.509 предусмотрены полезные расширения, носящие универсальный характер.

Каждое расширение включает имя, флаг критичности и значение. Если при обработке (проверке) сертификата встречается неизвестное расширение с флагом критичности FALSE, оно может быть проигнорировано; если же у подобного расширения флаг равен TRUE, сертификат приходится считать некорректным.

Сертификаты открытых ключей подразделяются на два основных вида:

сертификаты оконечных сущностей;сертификаты удостоверяющих центров.

Оконечные сущности не имеют права выпускать сертификаты. Удостоверяющие центры ведают выпуском и аннулированием сертификатов, которые относятся к одному из двух классов:

"самовыпущенные" сертификаты (изготовленные для себя самим удостоверяющим центром). Они полезны, например, при смене ключей УЦ, чтобы обеспечить доверие новым ключам на основании доверия старым. Важным подклассом данного класса являются "самоподписанные" сертификаты, в которых секретный ключ, использованный для генерации ЭЦП, соответствует заверяемому открытому ключу. Таким способом УЦ может афишировать свой открытый ключ или иную информацию о собственном функционировании;

кросс-сертификаты (выдаются одним УЦ другому). Они применяются и в иерархической структуре для авторизации нижестоящего УЦ вышестоящим, и в произвольной структуре "распределенного доверия" как факт признания одним УЦ существования другого.

Рассмотрим процесс получения и проверки пользователем A открытого ключа пользователя B. Элемент Директории, представляющий A, содержит один или несколько сертификатов открытых ключей A, заверенных удостоверяющим центром, который мы обозначим CA (A) (а сертификат A - как CA (A) <<A>>) и которому, разумеется, соответствует свой узел в Информационном Дереве. Предполагается, что пользователь доверяет своему УЦ, поэтому, если существует сертификат CA (A) <<B>>, процесс выяснения открытого ключа B можно считать завершенным. В противном случае приходится строить так называемый сертификационный маршрут от A к B (обозначается A -> B), начинающийся сертификатом CA (A) <<X1>>, который CA (A) выдал некоторому другому УЦ, X1, ставшему вследствие этого доверенным для A.


Маршрут продолжается сертификатом вида X1 <<X2>>, содержит промежуточные звенья вида Xi <<Xi+1>> и завершается сертификатом Xn <<B>>.

Элемент Директории, соответствующий удостоверяющему центру, содержит сертификаты двух типов: прямые (сгенерированные данным УЦ для других) и обратные (выданные данному УЦ другими). Если, кроме того, удостоверяющие центры образуют иерархию, соответствующую Информационному Дереву, то сертификационный маршрут можно построить без привлечения дополнительной информации, только на основе различительных имен   A и B. Действительно, с помощью обратных сертификатов выполняется подъем от CA (A) до корня поддерева, общего для A и B, а затем, с помощью прямых сертификатов осуществляется спуск до CA (B). В рассмотренном выше процессе A - пользователь сертификата, B - его владелец (субъект), CA (B) - удостоверяющий центр. Все три стороны несут друг перед другом определенные обязательства и, в свою очередь, пользуются предоставляемыми гарантиями. Обязательства и гарантии могут быть зафиксированы в политике сертификата, ссылка на которую хранится в одном из полей расширений. Обычно политика - это общепринятый текст, но в ней могут присутствовать и формальные условия, допускающие автоматическую проверку.

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

Другая группа дополнительных полей сертификатов обслуживает способы и срок действия ключей. Для шифрования и цифровой подписи применяют разные ключи; следовательно, у одного субъекта может быть несколько пар ключей и, соответственно, несколько сертификатов. Чтобы выбрать среди них нужный, необходимо иметь возможность выяснить назначение представленного в сертификате открытого ключа. Аналогично, может потребоваться знание срока годности секретного ключа, посредством которого формируют ЭЦП, поскольку этот срок обычно меньше, чем у открытого ключа, проверяющего подпись.

Значительная часть рекомендаций X.509 посвящена спискам отзыва сертификатов; мы, однако, не будем останавливаться на этом сугубо техническом вопросе.

описывают службу директорий. Среди

Рекомендации семейства X. 500 описывают службу директорий. Среди возможностей, предоставляемых этой службой, обычно выделяют дружественное именование (обращение к объектам по именам, удобным с точки зрения человека) и отображение имен в адреса (динамическое связывание объекта и его расположения - необходимое условие поддержки "самоконфигурируемости" сетевых систем).

Основные понятия службы директорий зафиксированы в рекомендациях X.501 "Служба директорий: модели" [50] и X.511 "Служба директорий: абстрактное определение сервиса" [52].

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

Информация, доступ к которой возможен посредством Директории, называется Информационной Базой Директории. Она обычно используется для облегчения взаимодействия таких сущностей, как объекты прикладного уровня, люди, списки рассылки и т.д., а также для получения сведений о них.

Предполагается, что Информационная База имеет древовидную структуру, называемую Информационным Деревом Директории. Вершины этого дерева, отличные от корня, составляют элементы Директории, в которых хранится информация об объектах.

У каждого элемента есть однозначно идентифицирующее его различительное имя. В пределах поддеревьев Информационного Дерева могут использоваться относительные различительные имена.

Природа объектов, информация о которых хранится в Директории, произвольна. Единственное требование к ним состоит в идентифицируемости (возможности именования).

Объекты объединяются в классы. Каждый объект должен принадлежать по крайней мере одному классу.

Элементы Директории могут быть составными, объединять подэлементы, содержащие информацию об отдельных аспектах объектов.

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

Некоторые из концевых узлов (листьев) Информационного Дерева могут представлять собой синонимы, содержащие альтернативное имя и указатель на элемент с информацией об объекте.



Служба директорий предоставляет две группы операций:



опрос;

модификацию.

В число операций опроса входят:



чтение значений атрибутов элемента Директории;

сравнение значения атрибута элемента Директории с заданной величиной (полезно, например, для проверки пароля без предоставления доступа к хранимому паролю);выдача списка (перечисление) непосредственных преемников заданного узла Информационного Дерева;

поиск и чтение элементов, удовлетворяющих заданным фильтрам (условиям), в заданных частях Информационного Дерева;

отказ от незавершенной операции опроса (например, если она выполняется слишком долго).

В группу операций модификации входят:

добавление нового (концевого) узла Информационного Дерева;удаление концевого узла Информационного Дерева;

модификация элемента Директории с возможным добавлением и/или удалением атрибутов и их значений;

модификация относительного различительного имени элемента или перемещение узла Информационного Дерева к другому предшественнику.

Рекомендации X.501 описывают три возможные схемы управления доступом к Директории: базовую, упрощенную и основанную на правилах; последняя может реализовывать принудительное (мандатное) управление доступом с использованием меток безопасности. Решения о предоставлении доступа принимаются с учетом существующей политики безопасности.

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

Таковы основные понятия и идеи службы директорий, зафиксированные в семействе рекомендаций X.500 и необходимые нам для последующего изложения.

Простая и сильная аутентификация

Каркасы сертификатов открытых ключей и атрибутов - основа целого ряда сервисов безопасности, в число которых входят аутентификация, контроль целостности, управление доступом. Они могут использоваться как самой Директорией, так и произвольными приложениями. В этом разделе мы рассмотрим простую и сильную аутентификации, включенные в рекомендации X.509.

Простая аутентификация предназначена только для локального использования. Данные для нее могут вырабатываться и передаваться тремя способами:

имя и пароль пользователя передаются в открытом виде;имя, пароль, случайное число и, возможно, временной штамп (метка) подвергаются воздействию односторонней функции, результат которой передается получателю для проверки;к описанному выше результату добавляется случайное число и/или временной штамп и еще раз применяется односторонняя функция (возможно, та же самая).

Рассмотрим более подробно реализацию разновидности 2 простой аутентификации. Пользователь A сначала генерирует токен безопасности   PT1:

PT1 = h1 (t1A, r1A, A, passwdA)

Токен PT1 используется для создания аутентификационного токена AT1:

AT1 = t1A, r1A, A, PT1

(т. е. токен AT1 состоит из четырех компонентов). Пользователь A пересылает пользователю B токен AT1. Цель B - своими средствами создать аналог токена безопасности PT1 (реконструировать PT1) и сравнить его с оригиналом. Он запрашивает у службы директорий или извлекает самостоятельно локальную копию пароля passwdA (обозначим ее passwdA-B) и реконструирует PT1:

PT1-B = h1 (t1A, r1A, A, passwdA-B)

Если PT1 и PT1-B совпадут, подлинность пользователя A считается установленной.

Сильная аутентификация основана на применении асимметричных методов шифрования, пригодных для генерации электронной подписи. Подлинность пользователя A считается установленной, если он продемонстрирует владение секретным ключом, ассоциированным с хранящимся в сертификате на имя A открытым ключом.

Рекомендации X.509 описывают три возможные процедуры сильной аутентификации:

односторонний обмен. От пользователя A пользователю B передается один токен. При этом подтверждается подлинность A и B, а также то, что токен сгенерирован A, предназначен B, не был изменен и является "оригинальным" (т. е. не посылается повторно);

двусторонний обмен. Дополнительно от B к A направляется ответ, допускающий проверку того, что он был сгенерирован B, предназначен A, не был изменен и является "оригинальным";

трехсторонний обмен. От A к B передается еще один токен. Обеспечивает те же свойства, что и двусторонний, без использования временных штампов.

Предполагается, что независимо от выбранной процедуры и до выполнения обменов пользователь A выясняет открытый ключ B и обратный сертификационный маршрут B -> A.

Рассмотрим более подробно процедуру одностороннего обмена.

В качестве первого шага пользователь A генерирует "уникальное" число rA, предназначенное для защиты от воспроизведения и подделки аутентификационного токена.

После этого A направляет B сообщение следующей структуры:

B -> A, A {tA, rA, B}

где tA - временной штамп, в общем случае представляющий собой пару (время генерации токена и срок его годности). (Напомним, что конструкция вида A {I} обозначает информацию I, подписанную открытым ключом A.)

Получив это сообщение, B предпринимает следующие действия:

по обратному сертификационному пути B -> A выясняет открытый ключ A (Ap), попутно проверяя статус сертификата A;проверяет подпись и, тем самым, целостность присланной информации;проверяет, что в качестве получателя указан B;удостоверяется, что временной штамп "свежий", а число rA ранее не использовалось.

Двусторонний и трехсторонний обмены являются довольно очевидным развитием одностороннего.

На этом мы завершаем рассмотрение рекомендаций семейства X.500.

<

Архитектура средств безопасности 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-уровня

Деление на уровни важно для всех аспектов информационных технологий. Там же, где участвует еще и криптография, важность возрастает вдвойне, поскольку приходится считаться не только с чисто техническими факторами, но и с особенностями законодательства различных стран, с ограничениями на экспорт и/или импорт криптосредств (см.

Контексты безопасности и управление ключами

Формирование контекстов безопасности в 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.

Обеспечение аутентичности 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 - это основа, на которой может строиться реализация виртуальных частных сетей, обеспечиваться защищенное взаимодействие мобильных систем с корпоративной сетью, защита прикладных потоков данных и т.п.

<

Протокольные контексты и политика безопасности

Системы, реализующие 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 или паре идентифицирующих цепочек). Получается, что способ идентификации (именования) навязывает трактовку области действия, что представляется неверным. На наш взгляд, вопросы именования могут решаться локально, а область действия контекста потенциально должна распространяться на произвольное число партнеров.

Основные идеи и понятия протокола TLS

Мы приступаем к рассмотрению протокола безопасности транспортного уровня (Transport Layer Security, TLS) (см. [42]), в котором получили дальнейшее развитие понятия, изложенные в версии 3.0 популярного протокола Secure Socket Layer (SSL) корпорации Netscape.

Посредством протокола TLS приложения, построенные в архитектуре клиент/сервер, могут защититься от пассивного и активного прослушивания сети и подделки сообщений.

TLS имеет двухуровневую организацию. На первом (нижнем) уровне, опирающемся на надежный транспортный сервис, каковой предоставляет, например, TCP, располагается протокол передачи записей (TLS Record Protocol), на втором (верхнем) - протокол установления соединений (TLS Handshake Protocol). Строго говоря, протокол безопасности транспортного уровня располагается между транспортным и прикладным уровнями. Его можно отнести к сеансовому уровню эталонной модели ISO/OSI.

Протокол передачи записей обеспечивает конфиденциальность и целостность передаваемых данных. Обеспечение конфиденциальности достигается путем применения методов симметричного шифрования (см. [91]), причем для каждого соединения генерируется свой секретный ключ. Контроль целостности (и, в частности, аутентичности) сообщений основан на использовании хэш-функций с секретными ключами.

Протокол установления соединений позволяет серверу и клиенту провести взаимную аутентификацию, согласованно выбрать алгоритм шифрования и криптографические ключи перед тем, как прикладной протокол начнет передачу данных. Для аутентификации сторон применяются методы криптографии с открытым ключом(см. [91]), при выработке совместных секретов обеспечивается конфиденциальность и целостность, в том числе защита от нелегального посредника.

В соответствии с уровневой организацией сетевых протоколов, TLS не зависит от протоколов прикладного уровня. Кроме того, он обеспечивает интероперабельность использующих его независимо написанных приложений или компонентов приложений; последние могут успешно согласовывать криптографические параметры в динамике, не располагая информацией о кодах друг друга.

По отношению к алгоритмам симметричного и асимметричного шифрования TLS представляет собой алгоритмически независимый, расширяемый каркас, допускающий добавление новых криптографических методов и их реализаций.

В спецификациях TLS фигурируют четыре криптографические операции: цифровая подпись, потоковое шифрование, блочное шифрование и шифрование открытым ключом. Все они, особенно асимметричное шифрование, способны поглотить много процессорного времени. Для решения этой проблемы определенное внимание уделено вопросам эффективности, минимизации нагрузки на процессор и сеть: предлагаемая схема кэширования в рамках сеанса уменьшает число соединений, устанавливаемых "с нуля".

В последующих разделах подробно рассматриваются составляющие протокола TLS и их использование.

Применение протокола HTTP над TLS

Применение протокола HTTP над TLS описано в спецификациях [76]. С концептуальной точки зрения, оно организовано весьма просто. HTTP/TLS-сервер слушает порт 443. HTTP/TLS-клиент, являясь, в частности, TLS-клиентом, начинает процесс установления соединения с посылки приветственного сообщения. По сформированному TLS-соединению направляются обычные HTTP-запросы и ответы на них, которые трактуются протоколом TLS как прикладные данные.

В уникальном идентификаторе ресурсов (URI) сочетание HTTP/TLS обозначается как "https":

https://www.example.com/home.html

Обычно после анализа URI клиент узнает имя хоста, на котором функционирует сервер. Это имя должно быть сопоставлено с тем, которое фигурирует в сертификате сервера. Если сервер задан IP-адресом, тот же адрес должен присутствовать в сертификате и подвергаться проверке.

В качестве сигнала окончания взаимодействия используется уведомление о завершении сеанса.

<

ContentType type; ProtocolVersion version; uint16

enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment [TLSPlaintext.length]; } TLSPlaintext;

Листинг 10.1. Начальная структура блока протокола передачи записей.

Закрыть окно

struct { ContentType type; /* Тот же, что и TLSPlaintext.type */ ProtocolVersion version; /* Та же, что и TLSPlaintext.version */ uint16 length; opaque fragment [TLSCompressed.length]; } TLSCompressed;

Листинг 10.2. Структура блока протокола передачи записей после сжатия.

Закрыть окно

key_block = PRF (SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); /* PRF - псевдослучайная функция */ /* "+" обозначает операцию конкатенации */

Листинг 10.3. Вычисление ключевого блока в протоколе передачи записей.

Закрыть окно

client_write_MAC_secret [SecurityParameters.hash_size] server_write_MAC_secret [SecurityParameters.hash_size] client_write_key [SecurityParameters.key_material_length] server_write_key [SecurityParameters.key_material_length] client_write_IV [SecurityParameters.IV_size] server_write_IV [SecurityParameters.IV_size] /* MAC - Message Authentication Code, */ /* аутентификационный код сообщения */ /* IV - Initialization Vector, */ /* начальный вектор */

Листинг 10.4. Параметры криптографических операций протокола передачи записей.

Закрыть окно

HMAC_hash (MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));

Листинг 10.5. Вычисление имитовставки в протоколе передачи записей.

Закрыть окно

stream-ciphered struct { opaque content [TLSCompressed.length]; opaque MAC [CipherSpec.hash_size]; } GenericStreamCipher; block-ciphered struct { opaque content [TLSCompressed.length]; opaque MAC [CipherSpec.hash_size]; uint8 padding [GenericBlockCipher.padding_length]; uint8 padding_length; } GenericBlockCipher; struct { ContentType type; ProtocolVersion version; uint16 length; select (CipherSpec.cipher_type) { case stream: GenericStreamCipher; case block: GenericBlockCipher; } fragment; } TLSCiphertext;

Листинг 10.6. Шифрование блока вместе с имитовставкой в протоколе передачи записей.

Закрыть окно

struct { uint32 gmt_unix_time; opaque random_bytes [28]; } Random; struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-1>; CompressionMethod compression_methods<1..2^8-1>; } ClientHello;

Листинг 10.7. Структура приветственного сообщения клиента в протоколе установления соединений.

Закрыть окно

struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; } ServerHello;

Листинг 10.8. Структура приветственного сообщения сервера в протоколе установления соединенийСтруктура приветственного сообщения клиента в протоколе установления соединений.

Закрыть окно

struct { opaque verify_data[12]; } Finished; Finished.verify_data = PRF (master_secret, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]; /* Хэшируются все сообщения, участвовавшие в */ /* установлении соединения */ /* Значениями параметра "finished_label" /* служат, соответственно, цепочка символов */ /*" client finished" на стороне клиента */ /* и "server finished" на стороне сервера. */

Листинг 10.9. Структура сообщения о завершении формирования сеанса в протоколе установления соединений.

Закрыть окно

master_secret = PRF (pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];

Листинг 10. 10. Вычисление мастер-секрета.

Закрыть окно

Протокол передачи записей

В общем виде функционирование протокола передачи записей можно представлять себе следующим образом. Сообщение, поступившее для передачи с более высокого протокольного уровня, включает длину, тип и содержимое. Оно разбивается на блоки (записи), допускающие эффективную обработку (или, наоборот, в один блок объединяется несколько небольших однотипных сообщений), сжимается, снабжается имитовставкой, шифруется, затем результат передается. На стороне получателя принятые данные расшифровываются, верифицируются, подвергаются декомпрессии и сборке, и затем сообщение доставляется клиенту на вышележащем протокольном уровне.

Спецификациями TLS предусмотрено четыре вышележащих клиента протокола передачи записей:

протокол установления соединений;

протокол оповещения (alert protocol);

протокол смены параметров шифрования (change cipher spec protocol);

протокол передачи прикладных данных (application data protocol).

Функции этих протоколов будут рассмотрены в следующем разделе.

С точки зрения протокола передачи записей, каждое соединение является двунаправленным и может находиться в одном из двух состояний: обработки (т. е. быть текущим) и ожидания (быть отложенным). Кроме того, состояние соединения характеризуется применяемыми алгоритмами (сжатия, шифрования, вычисления имитовставки) и их параметрами (секретными ключами и начальными векторами. Наконец, каждому соединению соответствуют четыре экземпляра состояния: по два на клиентской и серверной сторонах (любая из них может передавать и принимать данные).

Перечислим и другие элементы состояния соединения:

мастер-секрет - 48-байтное значение, разделяемое партнерами по общению и служащее для выработки других общих секретов (ключей шифрования и т.п.);два 32-байтных случайных значения, одно из которых предоставляется сервером, а другое - клиентом, но оба участвуют в выработке ключей и начальных векторов;два 64-битных порядковых номера передаваемой записи (по одному на сторонах отправителя и получателя) с нулевым начальным значением.

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

Формально процесс обработки данных протоколом передачи записей можно описать как последовательность преобразований структур (в спецификациях [42] для этой цели используется интуитивно понятный C-подобный язык).

На первом шаге выполняется фрагментация (или объединение однотипных) сообщений, предназначенных для передачи, в структуры TLSPlaintext размером не более 16384 байт (см. листинг 10.1).

enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType;

struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment [TLSPlaintext.length]; } TLSPlaintext;

Листинг 10.1. Начальная структура блока протокола передачи записей.

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

На втором шаге выполняется сжатие данных (естественно, без потери информации). Оно приводит к появлению следующей структуры (см. листинг 10.2).

struct { ContentType type; /* Тот же, что и TLSPlaintext.type */

ProtocolVersion version; /* Та же, что и TLSPlaintext.version */

uint16 length; opaque fragment [TLSCompressed.length]; } TLSCompressed;

Листинг 10.2. Структура блока протокола передачи записей после сжатия.

Далее следуют криптографические операции. К этому моменту на основе мастер-секрета и случайных значений, предоставленных сервером и клиентом, должен быть сгенерирован ключевой блок достаточной длины (см. листинг 10.3).

key_block = PRF (SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);

/* PRF - псевдослучайная функция */ /* "+" обозначает операцию конкатенации */

Листинг 10.3. Вычисление ключевого блока в протоколе передачи записей.

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


листинг 10.4).

client_write_MAC_secret [SecurityParameters.hash_size] server_write_MAC_secret [SecurityParameters.hash_size] client_write_key [SecurityParameters.key_material_length] server_write_key [SecurityParameters.key_material_length]

client_write_IV [SecurityParameters.IV_size] server_write_IV [SecurityParameters.IV_size]

/* MAC - Message Authentication Code, */ /* аутентификационный код сообщения */ /* IV - Initialization Vector, */ /* начальный вектор */

Листинг 10.4. Параметры криптографических операций протокола передачи записей.

С помощью сформированных параметров криптографических операций выполняется третий шаг протокола передачи записи, состоящий в вычислении имитовставки (см. листинг 10.5).

HMAC_hash (MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));

Листинг 10.5. Вычисление имитовставки в протоколе передачи записей.

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

На четвертом шаге выполняется шифрование блока вместе с имитовставкой (см. листинг 10.6).

stream-ciphered struct { opaque content [TLSCompressed.length]; opaque MAC [CipherSpec.hash_size]; } GenericStreamCipher;

block-ciphered struct { opaque content [TLSCompressed.length]; opaque MAC [CipherSpec.hash_size]; uint8 padding [GenericBlockCipher.padding_length]; uint8 padding_length; } GenericBlockCipher;

struct { ContentType type; ProtocolVersion version; uint16 length; select (CipherSpec.cipher_type) { case stream: GenericStreamCipher; case block: GenericBlockCipher; } fragment; } TLSCiphertext;

Листинг 10.6. Шифрование блока вместе с имитовставкой в протоколе передачи записей.

На стороне получателя действия выполняются в обратном порядке:

расшифрование;контроль целостности;декомпрессия;сборка сообщений.

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

Протокол установления соединений и ассоциированные протоколы

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

На рис. 10.1 показан процесс формирования сеанса. Звездочками помечены необязательные сообщения, в квадратные скобки заключено сообщение протокола смены параметров шифрования.

Рис. 10.1.  Процесс формирования сеанса

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

Новое соединение на основе существующего сеанса формируется более экономным образом (см. рис. 10.2).

Рис. 10.2.  Формирование нового соединения на основе существующего сеанса

Обычно новые сеансы и соединения формируются по инициативе клиента (например, при подсоединении к серверу), но и сервер может "намекнуть" клиенту на желательность подобного действия (если, например, пришло время смены криптографических параметров), послав запрос приветственного сообщения (HelloRequest).

Поясним структуру и назначение сообщений, приведенных на рисунках.

Приветственное сообщение клиента, открывающее процесс формирования сеанса или соединения, выглядит следующим образом (см. листинг 10.7).

struct { uint32 gmt_unix_time; opaque random_bytes [28]; } Random;

struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-1>; CompressionMethod compression_methods<1..2^8-1>; } ClientHello;

Листинг 10.7. Структура приветственного сообщения клиента в протоколе установления соединений.

Если идентификатор сеанса (session_id) пуст, имеется в виду формирование нового сеанса; в противном случае устанавливается новое соединение в рамках существующего сеанса.
Поля compression_methods и cipher_suites содержат списки предлагаемых клиентом алгоритмов сжатия и криптографии (в порядке убывания приоритетов). Они должны быть построены так, чтобы согласие между клиентом и сервером было заведомо возможным. В частности, в списке алгоритмов сжатия должен фигурировать пустой метод.

Сервер отвечает клиенту собственным приветствием, главное в котором - выбранные алгоритмы сжатия и криптографии (см. листинг 10.8).

struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; } ServerHello;

Листинг 10.8. Структура приветственного сообщения сервера в протоколе установления соединенийСтруктура приветственного сообщения клиента в протоколе установления соединений.

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

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

Если сертификат сервера не посылался или содержащихся в нем данных недостаточно, сервер должен отправить свой ключевой материал в отдельном сообщении. При желании сервер может запросить сертификат клиента.

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


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

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

Структура сообщения о завершении формирования сеанса (соединения) показана на листинге 10.9.

struct { opaque verify_data[12]; } Finished;

Finished.verify_data = PRF (master_secret, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11];

/* Хэшируются все сообщения, участвовавшие в */ /* установлении соединения */ /* Значениями параметра "finished_label" /* служат, соответственно, цепочка символов */ /*"client finished" на стороне клиента */ /* и "server finished" на стороне сервера. */

Листинг 10.9. Структура сообщения о завершении формирования сеанса в протоколе установления соединений.

Мастер-секрет вычисляется единообразно для всех методов выработки ключей ( см. листинг 10.10).

master_secret = PRF (pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];

Листинг 10.10. Вычисление мастер-секрета.

Участвующий в процессе формирования сеанса протокол смены параметров шифрования устроен предельно просто и заключает в себе один тип однобайтных сообщений.

Более содержательный протокол оповещения предназначен для передачи предупреждений и сообщений об ошибках. Наиболее употребительное предупреждение - уведомление о завершении сеанса.Типичные ошибки - неожиданное сообщение, неверная имитовставка, неверный параметр, ошибка расшифрования и т.п. После получения сообщения об ошибке соединение разрывается.

---

---