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

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

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

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

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

Недействительна будет и цифровая налоговая декларация физлица без ЭП.

Как заказать квалифицированную электронную подпись онлайн

Если по правилам КЭП необходимо оформлять исключительно лично, то как сделать квалифицированную электронную подпись для госуслуг онлайн? Примерно так, как сотрудники похоронного агентства самостоятельно получают для клиента свидетельство о смерти в ЗАГСЕ – решают все вопросы по своим каналам.

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

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

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

Для получения КЭП для госуслуг потребуется только гражданский паспорт и пенсионное свидетельство.

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

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

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

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

Полезное видео по теме — Электронная подпись: что это такое и как получить ЭЦП, ЭП?:

Глава вторая

Порывшись в почте, я нашел еще один электронный договор. По счастливой случайности, им тоже оказался страховой полис, но на этот раз еОСАГО от АО “Тинькофф Страхование”. Открываем сертификат, смотрим выпустившую сертификат организацию. Ей оказывается АО “Тинькофф банк”. Да, оказывается у них есть свой УЦ, который выдает сертификаты дочерним организациям (у Сбербанка тоже есть свой УЦ, но в дочерних структурах он не используется).

По отработанному алгоритму идём в поисковую систему с запросом “тинькофф сертификат”, находим официальный сайт УЦ АО Тинькофф Банк. Тут нас встречает изобилие ссылок на корневые сертификаты, списки отозванных сертификатов и даже видеоинструкция по их установке. Скачиваем “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2012”, на этот раз ссылка ведёт не на сторонний сервис, а на сайт банка. Формат файла P7B не очень известный, но открывается Windows без установки стороннего софта и показывает находящиеся в нём сертификаты. Здесь уже привычный корневой сертификат от Минкомсвязи (другой, не тот, что в первом случае) и промежуточный сертификат УЦ банка.

Ставим оба, проверяем сертификат в полисе. Но нет, сертификат не является доверенным, т.к. система не может подтвердить поставщика сертификата. На сайте УЦ было 2 ссылки на 2 цепочки сертификатов, один для ГОСТ Р 34.10.2001, другой для ГОСТ Р 34.10.2012. Полис был выпущен в этом году, логичнее бы его подписать уже более современным криптоалгоритмом (тем более уже есть версия ГОСТ от 2018 года, алгоритмы обновляются довольно часто), но давайте проверим старый.

В новом файле формата P7B оказывается уже 3 файла сертификатов. Можно поставить все 3, однако стоит заметить, что сертификат “Головного удостоверяющего центра” мы поставили в первой главе из RAR архива ООО “ИТК”, они идентичны. А сертификат с не очень говорящим названием “УЦ 1 ИС ГУЦ” поставил КриптоПро CSP, т.к. галочка об установке корневых сертификатов была установлена по-умолчанию в его инсталляторе. Единственным новым является сертификат АО “Тинькофф Банк”, который мы и ставим.

После установки сертификатов из “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2001” путь в сертификате прорисовался и система радостно сообщила, что он является доверенным. Adobe Acrobat Reader DC также подтвердил, что подпись действительна.

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

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

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

Время на прочтение

В информационном мире и 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)

“Для средств ЭП, техническое задание на разработку которых утверждено после 31 декабря 2012 года, должна быть предусмотрена реализация функций средства в соответствии с ГОСТ Р 34.10-2012 хотя бы по одному из определяемых стандартом вариантов требований к параметрам (использование варианта, соответствующего длине секретного ключа порядка 256 бит, является предпочтительным, поскольку обеспечивает достаточный уровень криптографической стойкости и лучшие эксплуатационные характеристики, в том числе при совместной реализации со схемой ГОСТ Р 34.10-2001). После 31 декабря 2013 года не осуществлять подтверждение соответствия средств ЭП Требованиям к средствам электронной подписи, утверждённым приказом ФСБ России от 27.12.2011 г. № 796, если в этих средствах не предусмотрена реализация функций средства в соответствии с ГОСТ Р 34.10-2012 хотя бы по одному из определяемых стандартом вариантов требований к параметрам. Исключение может быть сделано для средств ЭП, удовлетворяющих одновременно следующим условиям:
— техническое задание на разработку средства утверждено до 31 декабря 2012 года;
— в соответствии с техническим заданием разработка средства завершена после 31 декабря 2011 года;
— подтверждение соответствия средства указанным Требованиям ранее не осуществлялось.
Использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается. ”

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

В Постановлении Правительства России от 16 апреля 2012 г. №313 «Об утверждении Положения о лицензировании деятельности по разработке, производству, распространению шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнению работ, оказанию услуг в области шифрования информации, техническому обслуживанию шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя)»

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

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

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

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

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

Взаимодействие с регулятором

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

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

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

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

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

Здравствуйте!
В соответствии с выпиской из документа ФСБ России № 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

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

В какие сроки планируется проводить изменения и работы?

Будут ли какие-то предварительные объявления на портале 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 запросе на сертификат, к которому мы сможем передать свой открытый ключ, сгенерированный по новому алгоритму. Но об этом чуть позже.

Бесперебойная работа ПО

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

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

Обращаем внимание, что в связи с требованиями ФСБ России, сопряженными с запретом использования ГОСТ Р 34.10-2001 для формирования подписи после 1 января 2019 года (см. tc26.ru/info/new-national-standards), с 1 июля 2017 года в КриптоПро CSP версий 3.9 и 4.0, а также КриптоПро JCP 2.0 будут появляться предупреждения о необходимости скорого перехода на ГОСТ Р 34.10-2012 при формировании ключей ГОСТ Р 34.10-2001, а с 1 октября 2017 года – и при формировании подписи по ГОСТ Р 34.10-2001. Пользователь, обладающий правами администратора системы, при запуске приложения с правами администратора (UAC) может отложить предупреждения на месяц, установив соответствующий флаг в данном окне.
На случай если появление этих предупреждений в вашей системе нежелательно, вы можете заблаговременно их отключить.

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

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

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

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

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

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

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

Для отключения данных предупреждений в КриптоПро CSP до 1 января 2019 года на Unix-системах нужно добавить два ключа в конфигурационный файл /etc/opt/cprocsp/config64.ini (или /etc/opt/cprocsp/config.ini в случае 32-битной системы) в существующую секцию Parameters:

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

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

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

Получение новых сертификатов

У КриптоПро есть свои тестовые удостоверяющие центры

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

Мной было заведено обращение на на портал технической поддержки КриптоПро

Скажите, пожалуйста, планируется ли перевод тестового УЦ testca2.cryptopro.ru/UI на ГОСТ Р 34.10-2012 и если да, то в какие сроки?

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

Планируется, сроки не определены. Возможно это будет другой УЦ.

Сейчас появилась живая ссылка на тестовый УЦ КриптоПро, поддерживающий ГОСТ 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

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

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

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

private static final String GOST3411_2012_256 = «GOST3411_2012_256»;
private static final String GOST3411_2012_256WITH_GOST3410DH_2012_256 = «GOST3411_2012_256withGOST3410DH_2012_256»;
private static final String GOST3411_2012_512 = «GOST3411_2012_512»;
private static final String GOST3411_2012_512WITH_GOST3410DH_2012_512 = «GOST3411_2012_512withGOST3410DH_2012_512»;

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

Signature signature = Signature.getInstance(GOST3411_2012_512WITH_GOST3410DH_2012_512,config.getProperty(Config. CRYPTO_PROVIDER));

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

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

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

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

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

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

private static final String GOST3411_2012_256WITH_GOST3410DH_2012_256 = «GOST3411_2012_256withGOST3410DH_2012_256»;
private static final String GOST3411_2012_512WITH_GOST3410DH_2012_512 = «GOST3411_2012_512withGOST3410DH_2012_512»;

private static final OID OID_ALG_DIGEST_GOST_2012_256 = new OID(«1.2.643.7.1.1.2.2»);
private static final OID OID_ALG_SIGN_GOST_2012_256 = new OID(«1.2.643.7.1.1.1.1»);
private static final OID OID_ALG_DIGEST_GOST_2012_512 = new OID(«1.2.643.7.1.1.2.3»);
private static final OID OID_ALG_SIGN_GOST_2012_512 = new OID(«1.2.643.7.1.1.1.2»);

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

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

private static final OID OID_S_ALG_DIGEST_GOSTBC = new OID(«1.2.643.2.2.9»);
private static final OID OID_S_ALG_SIGN_GOSTBC = new OID(«1.2.643.2.2.19»);

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

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

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

MessageDigest digester = MessageDigest.getInstance(new OID(signerInfo.digestAlgorithm.algorithm.value).toString(), config.getProperty(Config. CRYPTO_PROVIDER));

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

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

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

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

Результат проверки подписи PKCS-7 ГОСТ Р 34. 11-2012/34. 10-2012 256 бит

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

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

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

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

Результат проверки подписи PKCS-7 ГОСТ Р 34. 11-2012/34. 10-2012 512 бит

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

Полезные ссылки

Все манипуляции с PDF документом приведены в чистой версии ОС Windows 10, русская домашняя редакция, как наиболее вероятной среде работы простого пользователя. Набор софта, используемый в статье, также является непрофессиональным и доступным для всех.

Для начала я открыл документ в просмотрщике Foxit Reader, который использую как основной:

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

Кроме имени организации, которой выдан сертификат, видно наименование выдавшей его организации, ООО “ИТК”. Поиск по запросу “ООО ИТК сертификат” вывел меня на страницу Установка корневого сертификата Удостоверяющего центра ООО «ИТК». Это официальный сайт ООО «Интернет Технологии и Коммуникации», который является одним из удостоверяющих центров, выдающих сертификаты ЭП.

Снова открываем сертификат из документа. И чуда не произошло, цепочка доверия от корневого до конечного не строится!

Изучаем ЭП подробнее: в Foxit Reader есть дополнительная информация о свойствах подписи:

Ага, алгоритм хеширования ГОСТовский, ЭП создана в КриптоПро PDF. Возможно, Windows не знает про ГОСТ шифрование и поэтому ему нужен дополнительный криптопровайдер.

Идём на сайт КриптоПро, регистрируемся, скачиваем пробную версию КриптоПро CSP 5.0 на 3 месяца. Что будет дальше — не совсем понятно, возможно всё превратится в тыкву, посмотрим.

Снова открываем просмотр сертификата ЭП:

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

Сообщение о проверке немного улучшилось, но всё равно Foxit Reader не может проверить сертификат (вероятно дело в ГОСТовском алгоритме):

В Adobe Acrobat Reader DC проверка тоже не успешна:

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

Вспоминаем, что полис подписан в программе КриптоПро PDF. Вероятно, что раз она может создавать такие подписи, то уж наверняка должна их и проверять. Ставим.

+1 триал версия на 90 дней, хотя вроде бы надпись при установке успокаивает, что при использовании продукта в Adobe Acrobat Reader DC лицензия не нужна.

Ура, долгожданное сообщение о том, что всё хорошо.

Подведем промежуточный итог. Для проверки действительности ЭП на документе нужно:

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

Как сделать электронную подпись для госуслуг в аккредитованных УЦ

Для начала немного терминологии.

Далее краткая пошаговая инструкция, как делается электронная подпись для портала государственных услуг Российской Федерации в одном из ближайших УЦ.

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

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

Вполне может оказаться, что выбранный вами УЦ не работает по желаемому типу КЭП и тогда придется продолжить поиски.

Продвинутые пользователи давно привыкли все сервисы заказывать через интернет. Нет времени на личный поход в удостоверяющий центр? Тогда приступаем к Плану «БЭ», как выражаются наши заокеанские партнеры.

Немного про корневые и промежуточные сертификаты

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

Однако просто списка недостаточно, нужны хотя бы ссылки на сайты этих УЦ, а также надо найти корневые сертификаты непосредственно от первоисточника, Минкомсвязи. Следующий точкой в поиске этой информации стал портал pravo.gov.ru, где перечислены ссылки на некоторые корневые сертификаты. Страница доступна только по http протоколу, контрольных сумм опять нет.

Приглядевшись, можно заметить, что первые 4 ссылки ведут на портал https://e-trust.gosuslugi.ru. Не совсем понятно, почему именно поддомен сайта госуслуг стал центральным в системе корневых сертификатов, но, кажется, тут приведена вся актуальная информация по корневым и промежуточным сертификатам.

На странице головного УЦ https://e-trust.gosuslugi.ru/MainCA приведены 10 корневых сертификатов от Минкомсвязи, для разных ГОСТ алгоритмов и с разными сроками действия. Тут же доступны слепки ключей, можно проверить, что скачанный сертификат никто не подменил. Сам сайт имеет сертификат от Thawte.

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

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

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

UPD 0: В комментариях подсказали онлайн сервис на портале госуслуг для проверки ЭП документов: https://www.gosuslugi.ru/pgu/eds. К сожалению, не заработало в моём случае, но может быть полезно.

UPD 1: После написания статьи мне подсказали, что есть ещё один криптопровайдер, ViPNet CSP, который тоже может помочь с ГОСТовскими криптоалгоритмами в системе. Одновременная установка его с КриптоПро CSP под вопросом.

КДПВ: edar, Pixabay

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

Всегда-ли вы проверяете ЭЦП в полученных электронных документах?

Проголосовали 73 пользователя.

Воздержались 28 пользователей.