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

В информационном мире и Digital-Банке само собой разумеется – Digital Security и Digital Signature.

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

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

Как применять криптографию в соответствии с законодательством и ладу с регуляторами?

Речь пойдет о правовых аспектах и об организационно-технических мероприятиях в рамках официального перехода на национальные стандарты в области криптографической защиты информации ГОСТ Р 34.11-2012 «Функция хэширования» и ГОСТ Р 34.10-2012 «Процессы формирования и проверки электронной цифровой подписи».

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

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

Федеральным законом от 4 мая 2011 г. № 99-ФЗ «О ЛИЦЕНЗИРОВАНИИ ОТДЕЛЬНЫХ ВИДОВ ДЕЯТЕЛЬНОСТИ» установлен перечень видов деятельности, подлежащих обязательному лицензированию.

Постановлением Правительства РФ № 957 от 21 ноября 2011 г. «ОБ ОРГАНИЗАЦИИ ЛИЦЕНЗИРОВАНИЯ ОТДЕЛЬНЫХ ВИДОВ ДЕЯТЕЛЬНОСТИ» утвержден «ПЕРЕЧЕНЬ ФЕДЕРАЛЬНЫХ ОРГАНОВ ИСПОЛНИТЕЛЬНОЙ ВЛАСТИ, ОСУЩЕСТВЛЯЮЩИХ ЛИЦЕНЗИРОВАНИЕ КОНКРЕТНЫХ ВИДОВ ДЕЯТЕЛЬНОСТИ»

К лицензируемым видам деятельности, которые курирует ФСБ РФ, относятся:

31 января 2014 выходит документ ФСБ России № 149/7/1/3-58 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования».

Здесь я позволю себе процитировать выписку из данного документа, которая опубликована на портале ТЕХНИЧЕСКОГО КОММИТЕТА ПО СТАНДАРТИЗАЦИИ «КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ» (ТК 26)

На кого нацелен этот документ?

• он нацелен в первую очередь на лицензированных разработчиков СКЗИ, которые сертифицируют свои криптографические провайдеры в ФСБ.
• на уполномоченный федеральный орган в области использования электронной подписи и одновременно Головной Удостоверяющий Центр (ГУЦ), которым в соответствии с Федеральным законом № 63 «Об электронной подписи» и Постановлением Правительства РФ №976 от 28.11.2011 является Министерство связи и массовых коммуникаций
• на удостоверяющие центры, которые в соответствии со статьей 16 ФЗ № 63 «Об электронной подписи» получают аккредитацию в ГУЦ «Минкомсвязь»
• на организации, например, Альфа-Банк, которые осуществляют коммерческую деятельность с применением средств криптографической защиты информации.

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

Например, пункт из перечня: «2. Разработка защищенных с использованием шифровальных (криптографических) средств информационных систем»

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

В пункте 6 Положения №313 приведены лицензионные требования к организациям лицензиатам.

На этом с правовыми аспектами, которые порой трудно читать, закончим. И перейдем к организационным мероприятиям.

ГУЦ «Минкомсвязь» имеет свой портал — это своего рода единая точка входа в (Public Key Infrastructure PKI) Инфраструктуру с открытым ключом в масштабах Российской Федерации. Там опубликован большой список нормативных документов, требования и порядок аккредитации удостоверяющих центров, реестр действующих аккредитованных УЦ и информация о доступности их сервисов.

Там же можно скачать XML-представление реестра аккредитованных УЦ

TSL — Trusted List of supervised/accredited Certification Service Providers. Этот список подписан электронной подписью Минкомсвязи, через него выстраивается доверие и пути сертификации.

В целом на площадке Госуслуги развернуто единое пространство Электронного правительства РФ. Большинство сервисов, которого стало возможным благодаря развертыванию национальной PKI и применению криптографии и квалифицированной электронной подписи.

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

В свете сказанного выше было принято решение задать следующие вопросы в Федеральный ситуационный центр электронного правительства (адрес sd@sc.minsvyaz.ru).

Мое письмо было принято в работу группой ГУЦ-Восход:

Здравствуйте! В соответствии с выпиской из документа ФСБ России № 149/7/1/3-58 от 31.01.2014 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования», Где говорится, что использование ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается и необходимо выполнить переход на новые стандарты ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012

Сообщите, пожалуйста, какого плана работы предусмотрены для осуществления перевода инфраструктуры Головного удостоверяющего центра Минкомсвязи России на работу с ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012

Будут ли меняться:

• корневой сертификат ГУЦ Минкомсвязи России?
• сертификаты ПАК «УЦ 1 ИС ГУЦ» и ПАК «УЦ 2 ИС ГУЦ» ?
• сертификат подписи TSLExt1.0.xml списка аккредитованных УЦ?
• (STREET=125375 г. Москва ул. Тверская д.7, CN=Подсистема «Реестры» ИС ГУЦ, O=Минкомсвязь России, L=Москва, ST=77 г.Москва, C=RU)
• — структура самого TSL-списка, опубликованного на портале e-trust.gosuslugi.ru/CA/DownloadTSL?schemaVersion=0 ?

Будут ли какие-то предварительные объявления на портале e-trust.gosuslugi.ru?

Что будет со старыми типами подписи СМЭВ?

Будет единовременный переход на СМЭВ 3 с новым алгоритмом подписи?

И получил следующие ответы:

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

Переход Головного удостоверяющего центра на новые госты планируется в первом полугодии 2018 года, соответственно сертификат ГУЦ Минкомсвязи России будет заменен в это же время. Сертификаты УЦ 1 ИС ГУЦ и УЦ 2 ИС ГУЦ и сертификат подписи TSL предположительно будут заменены в это же время.

Структуру TSL списка менять не планируется.

Информация о работах по переходу на новые госты будет опубликована на странице sc.minsvyaz.ru и minsvyaz.ru/ru/appeals/faq/66

Согласно вышеописанной выписке, после 1 января 2019 года не допускается формирование подписи на старых ГОСТ, т.е., исходя из нее, дожить они могут, но подписывать ими нельзя. Обязательный отзыв сертификатов на старых ГОСТ пока также не планируется. Перевод своих клиентов на новые ГОСТ аккредитованный УЦ осуществляет самостоятельно, по мере своих возможностей, какого-либо общего порядка по нему не предусмотрено.

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

Вопросы касательно СМЭВ я сформулировал в отдельном письме на тот же адрес и оно было маршрутизировано на группу PТК-CМЭВ, а затем команде ПАО «Ростелеком».

Получен такой ответ:

Вообще СМЭВ и подпись XMLDsig/XAdES это отдельная большая тема.

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

Тем более, почти все необходимое под рукой есть. Сертифицированные СКЗИ, поддерживающие новые алгоритмы КриптоПро CSP 4.0, Java API КриптоПро JCSP и КриптоПро JCP 2.0 есть.

Выполнить генерацию новых ключей можно.

Нужен был только УЦ в PKCS#10 запросе на сертификат, к которому мы сможем передать свой открытый ключ, сгенерированный по новому алгоритму. Но об этом чуть позже.

На сайте КриптоПро регулярно выходили новости об автоматическом включении в СКЗИ предупреждений про грядущий переход на новые стандарты, по требованию ФСБ РФ.

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

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

За примером далеко ходить не надо. Возьмем операционную систему Linux, информационную систему на Java и провайдер КриптоПро JCP 2.0, посредствам которого выполняется электронная подпись документов. Если не отключить своевременно уведомления о переходе на новые стандарты, то в информационной системе при попытке подписать документ возникнет ошибка:

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

В итоге предупреждение приводит к сбою в программе, подпись на документ не ставится.

Разумеется, для информационной системы, где идет поток обращений к провайдеру, запускать сервер X Window System, например, программу Xming на своей станции и подключаться с помощью PuTTY по SSH с включенной опцией X11 forwarding для того, что бы клиент КриптоПро JCP мог отображать все предупреждения на нашу станцию, мы не будем.

Поэтому отключаем уведомления в контрольной панели КриптоПро JCP, следуя инструкции.

Если информационная система на Java использует криптографический провайдер КриптоПро CSP через JavaCSP, то выполняем пункт инструкции:

Соответствующие напоминания КриптоПро CSP появляются при генерации ключей и нового запроса на сертификат в UI центра регистрации. Если указать в поле Криптопровайдер — Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider. Для новой ключевой пары будет появляться окно с предупреждением вида:

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

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

На момент написания статьи УЦ поддерживающий новые стандарты отсутствовал.

Был получен ответ:

Сейчас появилась живая ссылка на тестовый УЦ КриптоПро, поддерживающий ГОСТ 2012.

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

Выполнена генерация двух комплектов ключей с размерностями 256 и 512 бит и получены два сертификата, соответствующие новым стандартам ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012.

Напомню, в составе КриптоПро JCP можно найти много примеров в файле samples-sources.jar. В частности, там есть примеры подписи и проверки ЭП документов. Все остальное является по большому счету частными кастомизациями.

Провайдеры КриптоПро JCP и JCSP поддерживают следующие нужные нам алгоритмы хэш функции и подписи:

JCSP - CryptoPro Java CSP Provider JCP - CryptoPro Java Provider

MessageDigest - GOST3411_2012_256 MessageDigest - GOST3411_2012_512

Signature - GOST3411_2012_256withGOST3410DH_2012_256 Signature - GOST3411_2012_512withGOST3410DH_2012_512 Как красиво распечатать список установленных и готовых к работе в JVM криптографических провайдеров, поддерживаемых ими функций и реализуемых алгоритмов:

Для того чтобы существующие методы подписи по ГОСТ Р 34.10-2001 начали подписывать документ по ГОСТ Р 34.10-2012, потребовалось внести ряд небольших изменений.

Рассмотрим на примере создания CMS (PKCS#7) контейнера.

Добавить названия новых алгоритмов:

Инициализировать объект подписи с нужным алгоритмом:

Добавить в создаваемый CMS контейнер нужный идентификатор хэш-функции:

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

В этом же цикле выполняем хэширование:

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

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

Для проверки подписи в другом классе добавляем названия алгоритмов и новые OID-ы.

Идентификаторы OID и их древовидная структура описаны в стандартах ASN.1 ITU-T X.660 и ISO/IEC 9834. Стандарты и информацию, какой идентификатор, какой сущности привязан можно найти на oid-info.com

Правда, идентификаторы новых алгоритмов пока не добавлены в российский сегмент OID-ов. Переход ведь только грядет. А вот по алгоритмам 2001 года информация есть:

Далее в методе проверки подписи проверяем, что алгоритм хэш-функции, указанный в CMS-контейнере нам знаком:

Выполняем проверку алгоритмов digest-а и signature для каждой подписи внутри контейнера:

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

Инициализируем объект класса Signature c соответствующим алгоритмом:

На этом все нюансы программного перехода на стандарты ГОСТ 34.10-2012 и ГОСТ 34.11-2012 исчерпаны.

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

Вот так выглядит структура CMS с новыми идентификаторами алгоритмов в программе ASN1View (разработчик)

— в сервисе проверки ЭП на портале Госуслуги

«Подлинность документа не подтверждена», потому что сертификат выдан в тестовом УЦ и Электронное Правительство ничего про него не знает. Сама ЭП — верна.

— с помощью программы КриптоАрм

— в собственном программном обеспечении

— в сервисе проверки ЭП на портале Госуслуги

— с помощью программы КриптоАрм

В КриптоАРМ сертификат проверки ЭП считается действительным, потому что корневой сертификат нашего тестового УЦ я добавил в хранилище корневых доверенных центров сертификации своей операционной системы.