Протокол защиты транспортного уровня это

Обновлено: 28.04.2024

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ

Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)

Information technology. Cryptographic data security. The use of the russian cryptographic algorithms in the transport layer security protocol (TLS 1.2)

Дата введения 2019-02-01

Предисловие

1 РАЗРАБОТАНЫ Обществом с ограниченной ответственностью "КРИПТО-ПРО" (ООО "КРИПТО-ПРО")

2 ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 26 "Криптографическая защита информации"

4 ВВЕДЕНЫ ВПЕРВЫЕ

Правила применения настоящих рекомендаций установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящим рекомендациям публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящих рекомендаций соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Настоящие рекомендации содержат описание протокола безопасности транспортного уровня версии 1.2 (TLS 1.2), с криптонаборами на основе алгоритмов блочного шифрования "Магма" и "Кузнечик", описанных в ГОСТ Р 34.12-2015.

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

Примечание - Основная часть настоящих рекомендаций дополнена приложениями А-В.

1 Область применения

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

2 Нормативные ссылки

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

ГОСТ Р 34.10-2012 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи

ГОСТ Р 34.11-2012 Информационная технология. Криптографическая защита информации. Функция хэширования

ГОСТ Р 34.12-2015 Информационная технология. Криптографическая защита информации. Блочные шифры

ГОСТ Р 34.13-2015 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров

ГОСТ Р ИСО/МЭК 9594-8 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации

Р 50.1.113-2016 Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов электронной цифровой подписи и функции хэширования

Р 1323565.1.017-2018 Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов блочного шифрования

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

3 Термины, определения и обозначения

3.1 Термины и определения

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

3.1.1 криптонабор (cipher suite): Набор криптографических алгоритмов и их параметров, определяющий работу протокола TLS в рамках соответствующей данному криптонабору сессии.

3.1.2 согласованный криптонабор: Криптонабор, соответствующий идентификатору криптонабора, согласованному сторонами взаимодействия в процессе выполнения протокола Handshake, описанного в разделе 6.

3.1.3 открытый ключ сервера: Ключ, равный ключу проверки подписи, хранящемуся в сертификате сервера.

3.1.4 закрытый ключ сервера: Ключ, равный ключу подписи сервера, соответствующему ключу проверки подписи, хранящемуся в сертификате сервера.

Примечание - В настоящих рекомендациях термины "открытый ключ сервера", "закрытый ключ сервера" используются вместо терминов "ключ проверки подписи сервера", "ключ подписи сервера" в целях конкретизации способа их использования и указывают на то, что данные ключи не используются в протоколе TLS 1.2 для формирования подписи, а участвуют в выработке общего ключа при работе протокола Handshake (см. раздел 6).

3.2 Обозначения

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

x mod y - остаток от деления целого числа х на целое число у;

- множество байтовых строк длины s, . Строка принадлежит множеству , если . При s=0 множество состоит из единственной пустой строки длины 0;

| - конкатенация двух байтовых строк; для двух строк , их конкатенацией а|b называется строка ;

b[i..j] - строка , где и ;

INT(b) - число , где ;

- строка , соответствующая числу ;

- строка , соответствующая строке , .

n - параметр алгоритма блочного шифрования, называемый длиной блока; в рамках данного документа измеряется в байтах;

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

q - порядок подгруппы группы точек эллиптической кривой, соответствующей открытому ключу сервера;

Р - точка эллиптической кривой порядка q, соответствующей открытому ключу сервера;

О - нулевая точка эллиптической кривой;

- ключ проверки подписи, хранящийся в сертификате клиента;

- ключ подписи клиента, соответствующий ключу ;

- открытый ключ сервера;

- закрытый ключ сервера;

- байтовая строка со случайными данными, соответствующая полю ClientHello.random, описанному в 6.3.2;

- байтовая строка со случайными данными, соответствующая полю ServerHello.random, описанному в 6.3.3;

- алгоритм подписи на ключе K, описанный в 6.4.6;

HASH - хэш-функция ГОСТ Р 34.11-2012 с длиной выхода 32 байта (256 бит);

KEG - алгоритм генерации ключей экспорта, описанный в 6.4.5.1;

PRF - псевдослучайная функция PRF_TLS_GOSTR3411_2012_256, описанная в Р 50.1.113-2016;

КЕхр15 - алгоритм экспорта ключей, описанный в Р 1323565.1.017-2018, использующий блочных шифр, задающийся выбранным криптонабором;

Кlтр15 - алгоритм импорта ключей, описанный в Р 1323565.1.017-2018, использующий блочных шифр, задающийся выбранным криптонабором;

Примечание 1 - Для описания протокола в настоящих рекомендациях используется общепринятый язык представления (далее - язык представления TLS), описанный в [1]*.

* Поз. [1], [3], [4] см. раздел Библиография, здесь и далее по тексту. - Примечание изготовителя базы данных.

Примечание 2 - В настоящих рекомендациях все строковые константы приводятся в кавычках и представляются в кодировке ASCII.

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

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

Примечание 5 - В настоящих рекомендациях используются обозначения параметров эллиптических кривых в соответствии с ГОСТ Р 34.10-2012 (раздел 5).

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

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

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

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

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

Шифрование и дешифрование данных

Два типа ключей шифрования

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

Слой защищенных сокетов (SSL)

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

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

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

Шифрование трафика веб-браузера

Сертификаты безопасности и центры сертификации

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

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

Заключение

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

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

TLS (или SSL ) работает на моде клиент-сервер . Он отвечает следующим целям безопасности:

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

Специальная IETF рабочая группа позволила создать TLS и его UDP несвязанный режиме эквивалент , DTLS . С момента принятия IETF протокол TLS прошел четыре версии: TLS v1.0 в 1999 году, TLS v1.1 в 2006 году, TLS v1.2 в 2008 году и TLS v1.3 в 2018 году.

Резюме

Презентация

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

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

По состоянию на 2009 год TLS используется большинством веб-серверов . Интернет-пользователь может распознать, что транзакция зашифрована по нескольким признакам:

Исторический

Протокол SSL

Первая выпущенная версия SSL, SSL 2.0, имела ряд недостатков безопасности, включая возможность принудительного использования более слабых алгоритмов шифрования или отсутствие защиты для установления связи и связи. Возможность для злоумышленника выполнять атаки с усечением. Протоколы PCT 1.0, а затем SSL 3.0 были разработаны для решения основной части этих проблем, второй из которых быстро стал самым популярным протоколом для защиты обменов в Интернете.

1994 : SSL 1.0 . Эта первая спецификация протокола, разработанного Netscape, оставалась теоретической и так и не была реализована.
Февраль 1995 : публикация стандарта SSL 2.0 , первой фактически используемой версии SSL. Это также была первая реализация запрещенного SSL в марте 2011 года ( RFC 6176 ).
Ноябрь 1996 г . : SSL 3.0 , последняя версия SSL, которая вдохновит его преемника TLS. Его спецификации были переизданы в августе 2008 года в RFC 6101. Протокол был запрещен в 2014 году после публикации уязвимости POODLE , этот запрет был окончательно ратифицирован в июне 2015 года ( RFC 7568 ).

Протокол TLS

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

Первая профессиональная версия TLS 1.3 - wolfSSL , выпущенная в мае 2017 года.

TLS в промышленных приложениях

Современные промышленные сети, работающие по протоколу TCP / IP, все чаще используют безопасность TLS. Таким образом, протоколы для команд управления электрическими сетями, такие как IEC-61850, IEC-60870 и DNP3, объединяют TLS для защиты от кибератак.

Внедрение TLS приложениями

Поддержка браузерами

Большинство браузеров также являются клиентами TLS. Веб-браузеры, поддерживающие последнюю версию TLS 1.2 по умолчанию:

Apple Safari 7 и новее;
Google Chrome и Chromium 30 и последующие версии;
Microsoft Internet Explorer 11 и выше;
Mozilla Firefox 27 и более поздние версии;
Opera 17 и последующие;
Microsoft Edge.

Основные разработчики веб-браузеров объявили о прекращении поддержки TLS 1.1 и более ранних версий с весны 2020 года.

Аутентификация цифрового сертификата

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

Принцип работы в веб-браузерах

Когда пользователь входит на веб-сайт, использующий TLSv1.2 (или ниже), выполняются следующие шаги:

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

Начиная с TLSv1.3 , обмен сеансовым ключом должен производиться через Диффи-Хеллмана с эллиптическими кривыми ( ECDHE ): RSA больше не может использоваться для этого.

Атаки

В марте 2014 года в библиотеке OpenSSL была обнаружена программная уязвимость : Heartbleed , по ошибке появившаяся в обновлении OpenSSL, сделанном двумя годами ранее. Этот недостаток получил широкую огласку, в том числе в средствах массовой информации, как, например , червь I love you в 2000 году.

15 октября 2014 года исследовательская группа Google обнаружила недостаток в конструкции SSLv3, позволяющий расшифровывать контент. Эта атака была названа POODLE для Padding Oracle On Downgraded Legacy . Он присутствует только в SSLv3.

2 марта 2016 г. исследователи подробно описали уязвимость под названием DROWN . Он заключается в использовании старой версии SSL v2 для расшифровки технологии TLS v1.2.

Целью протокола DANE является исправление некоторых слабых мест в TLS, в частности, для атак типа MIMT .

Технические характеристики

Аутентификация

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

Детали протокола

Криптография

Безопасность достигается, с одной стороны, с помощью асимметричного шифрования , такого как шифрование RSA , которое позволяет после аутентификации открытого ключа сервера создавать секрет, совместно используемый клиентом и сервером, с другой стороны, с помощью симметричного шифрования. (намного быстрее, чем асимметричные шифры), такие как AES , который используется на этапе обмена данными с симметричными ключами шифрования, вычисляемыми из общего секрета. Хэш - функция , такие как SHA-1 , также используется, помимо прочего, для обеспечения целостности данных и аутентификации (например , с помощью HMAC ).

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

Всего существует пять типов криптографических ключей, используемых во время сеанса TLS:

Открытые / закрытые ключи Диффи-Хеллмана сервера и клиента: для обмена секретом через алгоритм Диффи-Хеллмана, если он используется
Закрытые ключи сервера и клиента: для подписи данных, отправленных на этапе секретного обмена. Подпись данных не является обязательной и зависит от согласования криптографических комплектов.
Открытые ключи сервера и клиента: для проверки подлинности однорангового узла на этапе секретного обмена. Проверка не является обязательной и зависит от согласования криптографических комплектов. В случае, когда обмен секретом выполняется RSA, а не Diffie-Hellman, секрет шифруется открытым ключом сервера перед отправкой клиентом. Эти ключи предоставляются на этапе установления связи через электронные сертификаты.
Ключи шифрования сервера и клиента: для шифрования данных приложения. В зависимости от используемых функций шифрования их также можно использовать для аутентификации данных приложения.
MAC-ключи сервера и клиента: для аутентификации данных приложения, если функция шифрования не позволяет это

Используемые криптографические наборы имеют следующий формат:

Для TLS 1.2: TLS_KE_CIPHER_HASH.
Для TLS 1.3: TLS_CIPHER_HASH

где KE указывает алгоритм обмена секретами, CIPHER - алгоритм симметричного шифрования, а HASH - хеш-функцию . Функция HMAC является производной от хеш-функции.

Например, криптографический набор TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 указывает, что одноранговый узел может использовать алгоритм обмена эфемерными ключами Диффи-Хеллмана на эллиптических кривых, аутентифицированных алгоритмом подписи ECDSA, алгоритм AES 128 имеет симметричный алгоритм шифрования в режиме GCM и функцию SHA256.

В связи с требованием регуляторов по защите информации при обработке и передаче персональных данных в Банке реализована возможность работы по каналам связи защищенных согласно ГОСТ Р 34.10-2012.

MTLS - Mutual TLS, в переводе двухсторонний TLS или двухсторонний SSL, предоставляет возможность взаимной или двухсторонней аутентификации.

TLS - Transport Layer Security, протокол защиты транспортного уровня, основан на протоколе SSL (Secure Sockets Layer).

SSL - Secure Sockets Layer — уровень защищённых сокетов.

X.509 — стандарт ITU-T для инфраструктуры открытого ключа ( Public key infrastructure , PKI ) и инфраструктуры управления привилегиями ( Privilege Management Infrastructure ). Формат сертификта X.509 определяет стандартные форматы данных и процедуры распределения открытых ключей с помощью соответствующих сертификатов с цифровыми подписями

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

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

2. Требования к сертификату.

3. Порядок выпуска промышленного сертификата.

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

4. Порядок повторного выпуска промышленного сертификата.

Партнер заблаговременно, не позднее чем за месяц до истечения строка действия текущего сертификата, обращается в АУЦ с целью пере выпуска сертификата и закрытого ключа. Контроль за сохранностью и сроками действия сертификатов возлагается на Партнера. Банк не несет ответственность из-за утраты доступа к его сервисам случае, если Партнер по каким-либо причинам, утратил сертификат, не пере выпустил или не выполнил установку сертификата на своей стороне. В случае смены АУЦ необходимо заблаговременно предоставить корневой сертификат данного АУЦ, aдреса размещения списков отозванных сертификатов (CRL) и служб актуальных статусов сертификатов (OCSP).

5. Подготовительные работы.

Работа с сертификатами ГОСТ Р 34.10-2012 имеет ряд особенностей:

1) виду того, что УЦ Банка не уполномочен выпускать сертификаты с алгоритмом шифрования ключа ЭП ГОСТ Р 34.10-2012, в том числе тестовых,

Партнеру необходимо обратиться в АУЦ с целью выпуска сертификата;

2) на стороне партнера должны быть установлены СКЗИ обеспечивающие:

- формирование и проверку ЭП по ГОСТ Р 34.10-2012;

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

- обеспечение аутентичности, конфиденциальности и имитозащиты соединений по протоколам TLS;

- контроль целостности системного и прикладного программного обеспечения для его защиты

от несанкционированных изменений и нарушений доверенного функционирования.

6. Порядок вызова сервисов с использованием сертификата с алгоритмом шифрования ключа ЭП ГОСТ Р 34.10-2012.

Для вызова сервисов API используется три точки входа:

Вызов сервисов с использованием RSA сертификата:

Вызов сервисов с использованием промышленного ГОСТ Р 34.10-2012 сертификата:

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

Основной проблемой Интернета как канала передачи информации является возможность атаки “man in the middle”. Злоумышленник подключается к линии между клиентом и сервером и подменяет передающуюся информацию. Возможны совершенно разные варианты этой атаки. Например, злоумышленник может "прикидываться" сервером и вводить клиента в заблуждение с целью извлечь выгоду из обмана. Следует отметить, что наиболее легко эту атаку может реализовать Интернет-провайдер. С целью обеспечения безопасного обмена разработаны различные протоколы защиты и созданы программные продукты, реализующие данные протоколы. Во всех подобных протоколах используются методы криптографии. Именно криптография позволяет:

Эти меры позволяют успешно противостоять атаке "man in the middle".

Защита на различных уровнях модели OSI

Наиболее распространенной моделью представления стека сетевых протоколов является модель OSI. Упрощенная модель OSI представлена на рисунке.

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

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

Канальный уровень

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

Рассмотрим задачи, которые возможно решить с помощью OpenVPN в режиме "мост".

Подключение удаленного сотрудника к корпоративной ЛВС (VPN-шлюз)

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

Объединение ЛВС филиалов организации в единую сеть

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

Объединение сегментов ЛВС нескольких организаций в единую сеть для ведения совместного проекта (межкорпоративный портал)

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

Подключение к ЛВС удаленных пользователей с низким уровнем доверия

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

Создание нескольких логических сетей в одной физической сети

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

Под серфингом понимаются любые действия пользователя в Интернет. При этом интернет-провайдеру данного пользователя становятся известны web-сайты, на которые ходил пользователь; адресаты писем пользователя и т.п. Использование OpenVPN в качестве дополнительного "логического" шлюза в интернет, установленного на территории организации, в которой работает пользователь, обеспечивает анонимность серфинга.

Доступ к серверу, не имеющему внешнего адреса (экономия внешних адресов)

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

В качестве "криптографического ядра" OpenVPN использует библиотеку OpenSSL. Фирмой Криптоком создана сертифицированная в ФСБ версия данной библиотеки – СКЗИ МагПро КриптоПакет. Кроме того, создан коммерческий продукт OpenVPN-ГОСТ. Данный продукт является полным аналогом OpenVPN, но все криптографические операции в нем производятся по алгоритмам ГОСТ 28147-89, ГОСТ 34.11-2012, ГОСТ 34.10-2012 с использованием сертифицированного СКЗИ МагПро КриптоПакет.

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

Защита соединений на транспортном уровне (TCP-соединений) осуществляется по протоколу SSL/TLS. После установки транспортного соединения клиент инициирует процедуру "рукопожатия" с сервером. В результате этой процедуры происходит аутентификация сервера и клиента по цифровому сертификату, стороны договариваются об используемых алгоритмах шифрования – шифрсьютах. Шифрсьюты специальным образом "привязываются" к портам защищаемого соединения. Благодаря этому, все данные, попадающие в настроенный таким образом транспортный канал, шифруются отправителем и расшифровываются адресатом.

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

Часто бывает, что приложение было написано без защиты, или же используемые им шифрсьюты не удовлетворяют требованиям к безопасности. Например, все web-браузеры и web-сервера используют для защиты шифрсьюты, реализованные по импортным алгоритмам, а в РФ ФСБ требует в ряде случаев использовать шифрсьюты, реализованные по ГОСТ.

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

Именно такую схему можно реализовать с помощью продуктов КриптоТуннель.

Использование этих продуктов позволяет обеспечить защиту практически любых прикладных протоколов и приложений, как-то:

Представленные средства защиты транспортного уровня являются исполнениями СКЗИ МагПро КриптоПакет, сертифицированного в ФСБ, и поэтому удовлетворяют всем требованиям регуляторов безопасности.

Читайте также: