ВВЕДЕНИЕ

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

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

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

В подавляющем большинстве методов строгой аутентификации, контроля целостности и конфиденциальности данных используются криптография. Криптографические преобразования лежат в основе таких технологий безопасности как: виртуальные частные сети – VPN, электронная цифровая подпись –ЭЦП, инфраструктура распределения открытых ключей – PKI, строгая аутентификация и некоторых других.

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

АУТЕНТИФИКАЦИЯ  ОБНОВЛЕНИЙ МАРШРУТОВ И УПРАВЛЕНИЕ КОНФИГУРИРОВАНИЕМ

Маршрутизаторы контролируют доступ из сети в сеть. Они представляют сети и определяют тех, кто может получить к ним доступ. Поэтому маршрутизатор – это «лучший  друг хакера». Безопасность маршрутизаторов является критически важным элементом любой системы сетевой безопасности. Основной функцией маршрутизаторов является предоставлений доступа, и поэтому их нужно обязательно защищать, чтобы исключить возможность прямого взлома. При этом должны быть обеспечены следующие механизмы защиты:

- блокировка  доступа  из  сетей  общего  пользования,

- блокировка доступа к маршрутизатору через протокол SNMP,

- управление доступом к маршрутизатору через процедуры аутентификации,

- отключение ненужных услуг,

- вход в систему на определенных уровнях,

- аутентификация обновлений маршрутов.

Для примера рассмотрим простой сценарий организации безопасной связи с использованием шифрования при обновлении маршрутов. В данном случае маршрутизатор и межсетевой экран (реализующий демилитизированную зону для сети) имеют по одной паре открытых/секретных ключей. Удостоверяющий центр сертификатов открытых ключей (СА) получил сертификаты в формате X.509 для маршрутизатора и межсетевого экрана по доверенным каналам (семейство требований FTP_ITC «Общих критериев») [1,2,3]. Далее предположим, что маршрутизатор и межсетевой экран тоже получили копии открытого ключа СА по защищенным каналам. Теперь, если на на маршрутизаторе имеются данные, предназначенные для межсетевого экрана, и если маршрутизатор хочет обеспечить аутентификацию и конфиденциальность данных, необходимо предпринять следующие шаги:

1. Маршрутизатор отправляет в СА запрос на получение открытого ключа  межсетевого экрана,
2. СА отправляет ему сертификат межсетевого экрана, зашифрованный секретным ключом СА.
3. Маршрутизатор расшифровывает сертификат открытым ключом СА и получает открытый ключ межсетевого  экрана.
4. Межсетевой экран направляет СА запрос на получение открытого ключа маршрутизатора.
5. СА отправляет ему сертификат маршрутизатора, зашифрованный секретным ключом СА.
6. Межсетевой экран расшифровывает сертификат открытым ключом СА и получает открытый ключ маршрутизатора.
7. Маршрутизатор и межсетевой экран используют алгоритм Диффи-Хеллмана [4] и шифрования с помощью общих ключей для строгой аутентификации.
8. С помощью секретного ключа, полученного в результате использования алгоритма Диффи–Хеллмана, маршрутизатор и межсетевой экран производят обмен конфиденциальными данными.

Таким образом реализуется семейство требований FTP_TRP «Общих критериев» -доверенный маршрут.

КРИПТОГРАФИЯ  СРЕДСТВ  БЕЗОПАСНОСТИ  IP-УРОВНЯ

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

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

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

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

Архитектура средств безопасности для IP-уровня специфицирована в документе [5]. Ее основные составляющие представлены на рис.1. Это, прежде всего, протоколы обеспечения аутентичности (протокол аутентифицирующего заголовка — Authentication Header, АН) и конфиденциальности (протокол инкапсулирующей защиты содержимого -Encapsulating Security Payload, ESP), а также механизмы управления криптографическими ключами. На более низком архитектурном уровне располагаются конкретные алгоритмы шифрования, контроля целостности и аутентичности. Наконец, роль фундамента выполняет так называемый домен интерпретации (Domain of Interpretation, DOI), являющийся, по сути, базой данных, хранящей сведения об алгоритмах, их параметрах, протокольных идентификаторах и т.п.

Рис. 1. Основные элементы архитектуры средств безопасности IP-уровня.

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

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

Алгоритмическая независимость протоколов, к сожалению, имеет и оборотную сторону, состоящую в необходимости предварительного согласования набора применяемых алгоритмов и их параметров, поддерживаемых общающимися сторонами. Иными словами, стороны должны вы­работать общий контекст безопасности (Security Association, SA) и затем использовать такие его элементы, как алгоритмы и их ключи. Протоколы обеспечения аутентичности и конфиденциальности могут применяться в двух режимах: транспортном и туннельном. В первом случае защищается только содержимое пакетов и, быть может, некоторые поля заголовков. Как правило, транспортный режим используется хоста­ми. В туннельном режиме защищается весь пакет — он инкапсулируется в другой IP-пакет. Туннельный режим обычно реализуют на специально выделенных защитных шлюзах (в роли которых могут выступать маршрутизаторы или межсетевые экраны.

КОНТЕКСТЫ БЕЗОПАСНОСТИ И УПРАВЛЕНИЕ КЛЮЧАМИ

Формирование контекстов безопасности в IPsec разделено на две фазы. Сначала создается управляющий контекст, назначение которого — предоставить доверенный канал FTP_ITC (в терминологии «Общих критериев»), т. е. аутентифицированный, защищенный канал для выработки (в рамках второй фазы) протокольных контекстов и, в частности, для формирования криптографических ключей, используемых протоколами АН и ESP.

В принципе, для функционирования механизмов IPsec необходимы только протокольные контексты; управляющий играет вспомогательную роль. Более того, явное выделение двух фаз утяжеляет и усложняет формирование ключей, если рассматривать последнее как однократное действие. Тем не менее, из архитектурных соображений управляющие контексты не только могут, но и должны существовать, поскольку обслуживают все протокольные уровни стека TCP/IP, концентрируя в одном месте необходимую функциональность. Первая фаза начинается в ситуации, когда взаимодействующие стороны не имеют общих секретов (общих ключей) и не уверены в аутентичности друг друга. Если с самого начала не создать доверенный канал, то для выполнения каждого управляющего действия с ключами (их модификация, выдача диагностических сообщений и т.п.) в каждом протоколе (АН, ESP, TLS и т.д.) этот канал придется формировать заново.

Общие вопросы формирования контекстов безопасности и управления ключами освещаются в спецификации [5] — «Контексты безопасности и управление ключами в Internet» (Internet Security Association and Key Management Protocol, ISAKMP). Здесь вводятся две фазы выработки протокольных ключей, определяются виды управляющих информационных обменов и используемые форматы заголовков и данных. Иными словами, в [5] строится протокольно-независимый каркас.

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

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

В простейшем случае секретные ключи задаются заранее (ручной метод распределения ключей). Для небольших сетей такой подход вполне работоспособен, но он не является масштабируемым. Последнее свойство может быть обеспечено при автоматической выработке и распределении секретных ключей в рамках протоколов, основанных на алгоритме Диффи-Хелмана. Пример тому — «Протокол для обмена ключами в Internet» (The Internet Key Exchange, IKE).

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

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

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

В сообщениях (3) и (4) инициатор и партнер отправляют свои части ключевого материала, необходимые для выработки общего секретного ключа (мы опускаем детали, специфичные для алгоритма Диффи-Хелмана).

Рис. 2. Формирование управляющего контекста.

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

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

В представленном виде протокол формирования управляющего контекста защищает от атак, производимых нелегальным посредником, а также от нелегального перехвата соединений. Для защиты от атак на доступность, для которых характерно прежде всего навязывание интенсив­ных вычислений, присущих криптографии с открытым ключом, применяются так называемые идентифицирующие цепочки (cookies). Эти цепочки, формируемые инициатором и его партнером с использованием текущего времени (для защиты от воспроизведения), на самом деле присутствуют во всех ISAKMP-сообщениях и в совокупности идентифицируют управляющий контекст (в первом сообщении, по понятным причинам, фигурирует только цепочка инициатора). Согласно спецификациям [5], заголовок ISAKMP-сообщения имеет вид, изображенный на рис. 3. Если злоумышленник пытается «завалить» кого-либо запросами на создание управляющего контекста, подделывая при этом свой IP-адрес, то в сообщении (3) (см. выше рис. 2) он не сможет предъявить идентифицирующую цепочку партнера, поэтому до выработки общего секретного ключа и, тем более, электронной подписи и полномасштабной проверки аутентичности дело попросту не дойдет.

Рис. 3. Формат заголовка ISAKMP-сообщения.

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

ОСОБЕННОСТИ  НАЦИОНАЛЬНЫХ  ЗАКОНОДАТЕЛЬСТВ  И  ОГРАНИЧЕНИЯ  НА  ИСПОЛЬЗОВАНИЕ  СРЕДСТВ  КРИПТОГРАФИЧЕСКОЙ  ЗАЩИТЫ  ИНФОРМАЦИИ

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

-     сертификация средств криптографической защиты информации (СКЗИ);

- лицензирование деятельности организаций и предприятий, связанной с производством,  распространением, эксплуатацией и т.д. СКЗИ;

-      экспортно-импортные ограничения на СКЗИ.

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

В этой связи определенный интерес вызывает законодательство США в области экспорта СКЗИ, поскольку именно американские СКЗИ занимают доминирующее положение на мировом рынке. Итак, коротко рассмотрим «особенности национальной охоты» по-американски. Базовым законодательным актом в этой области является директива Президента США «Об управлении шифрованием в обществе» (Public Encryption Management), которая однозначно устанавливает, что экспортируемые из США СКЗИ не должны служить препятствием для органов электронной разведки США при добывании ими необходимой информации в компьютерных сетях на территории любой страны земного шара. Другими словами, если какое-то СКЗИ было экспортировано из США, это однозначно свидетельствует о том, что соответствующим компетентным органам этой страны (и, скорее всего, не только этой) не составляет особого труда «взломать» данное средство.

Справедливость такого утверждения можно легко продемонстрировать на следующем практическом примере. Известно, что абсолютное большинство представленных на  рынке стран СНГ продуктов американского производства, имеющих встроенные СКЗИ (а это все без исключения VPN-продукты), поставляются с криптоалгоритмом симметричного шифрования DES с длиной ключа 56 бит (для сравнения — национальные стандарты РБ и РФ предписывают длину ключа 256 бит).  Ориентировочные расчеты показывают, что время и материальные средства, которые необходимо затратить на взлом этого алгоритма методом «грубой силы», то есть путем полного перебора всех возможных ключей с использованием как стандартных компьютеров, так и специализированных криптоаналитических аппаратных средств не велики.

Характерно, что для приобретения СКЗИ с более криптостойким алгоритмом 3DES с длиной ключа 128 бит иностранным компаниям необходимо получать специальное разрешение со стороны Государственного департамента США.

Законодательство Республики Беларусь также имеет ряд законодательных актов и стандартов, призванных регулировать использование СКЗИ на территории РБ [6-12]. Отметим кратко те положения, которые прямо относятся к построению систем и средств защиты информации, в том числе с использованием криптографических методов, и попробуем их прокомментировать:

1.      Деятельность организаций и предприятий, связанная с проведением работ (производство, реализация, эксплуатация и т.д.) в области защиты информации, подлежит обязательному лицензированию. Лицензирование деятельности организаций и предприятий по защите информации, представляющей государственную тайну, на территории РБ осуществляет КГБ Республики Беларусь.

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

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

4.      Государственным организациям, предприятиям и банкам, а также предприятиям, работающим по государственному заказу, запрещено использование СЗИ и СКЗИ, не имеющих сертификатов государственного образца.

5.      Ввоз-вывоз СКЗИ может быть разрешен таможенными органами только на основании соответствующего разрешения КГБ после проведения необходимой технической экспертизы. Это в первую очередь требует обязательного проведения технической экспертизы СЗИ при пересечении границы РБ на предмет их отнесения к шифровальным средствам.

ЗАКЛЮЧЕНИЕ

1. Несмотря на международные стандарты и рекомендации, предписывающие инвариантность средств защиты информации, использующих криптографические преобразования по отношению к использованию криптографических алгоритмов, иностранные СЗИ поставляются с закрытым интерфейсом для встраивания национальных криптопровайдеров.
2. Закрытость криптографических интерфейсов преследует как коммерческие цели  (привязка потребителя к определенному поставщику/производителю), так и специальные, о которых говорилось выше.
3. Уровень доверия (гарантии оценки) к таким средствам низкий. По действующей в РБ нормативно-правовой базе в области защиты информации в соответствии с [3] поставляемые средства могут быть сертифицированы в Национальной системе сертификации не выше УГО1.
4. Отечественным партнерам иностранных производителей СЗИ, поставляющим их продукцию на рынки РБ, при составлении контрактов поставок рекомендуется настаивать на предоставление расширенных спецификаций технической документации (включающей проекты верхнего и нижнего уровня) и открытого криптографического интерфейса, дабы претендовать на уровень доверия при сертификации продукции, дотягивающий хотя бы до УГО3. Этот минимальный уровень доверия открывает поставщикам СЗИ достаточно обширный сектор рынка.

Литература

1. СТБ 34.101.1-2004 (ИСО/МЭК 15408-1:99) «Информационные технологии и безопасность. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель».

2. СТБ 34.101.2-2004 (ИСО/МЭК 15408-2:1999) «Информационные технологии и безопасность. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности».

3. СТБ 34.101.3-2004 (ИСО/МЭК 15408-3:1999) «Информационные технологии и безопасность. Критерии оценки безопасности информационных технологий. Часть З. Гарантийные требования безопасности».

4. Диффи У., Хеллман М.Э. Защищённость и имитостойкость: Введение в криптографию //ТИИЭР.—1979.—Т.67.-№3—С.71-109.

5. Kent S., Atkinson R. Security Architecture for Internet Protokol.—Request for Coments (RFC):2401, November 1998.

6. Указ Президента Республики Беларусь от 17 июля 2001г. №390 «Об утверждении Концепции национальной безопасности Республики Беларусь» //Национальный реестр правовых актов Республики Беларусь,2001 г., №69, 1/2852.

7. Декрет Президента Республики Беларусь от 14 июля 2003 г., № 17 «О лицензировании отдельных видов деятельности» //Национальный реестр правовых актов Республики Беларусь, 2005 г., №7,1/6166,№40,1/6300.

8. Постановление Комитета государственной безопасности Республики Беларусь от 12 декабря 2003 г. №23 «Об организации выдачи специальных разрешений (лицензий) на осуществление деятельности, связанной с криптографической защиты информации и средствами негласного получения информации»//Национальный реестр правовых актов Республики Беларусь. 2004 г.,  №6,8/10390.

9. Постановление Совета Министров Республики Беларусь от 20 октября 2003 г. №1374 «Об утверждении Положения о лицензировании деятельности по технической защите информации, в том числе криптографическими методами, включая применение электронной подписи» //Национальный реестр правовых актов Республики Беларусь, 2003 г., №121, 5/13254.

10. СТБ 1176.1-99 «Информационная технология. Криптографическая защита информации. Функция хэширования»

11. СТБ 1176.2-99 «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверка электронной цифровой подписи».

12. ГОСТ 28147-89 «Системы обработки информации. Защита криптографическая.  Алгоритм криптографических преобразований».



В.А. Артамонов, Е.В. Артамонова

Отправить статью в социальные сети, на печать, e-mail и в другие сервисы: