И вот, когда я уже практически добавил в криптографический АРМ на базе токенов PKCS#11 cryptoarmpkcs генерацию самоподписанных сертификатов и готов был приступить к написанию статьи, мне пришло такое письмо:

Мы являемся УЦ «Имярек», у нас возникло затруднение с выпуском ЭП в формате pkcs#11 для ЕГАИС, портал не понимает ЭП в формате «Имярек» CSP, просим Вас помочь в данной проблеме.

Я еще не знал всех тонкостей работы с ЕГАИС, но поскольку речь шла о PKCS#11, то предложил воспользоваться утилитой cryptoarmpkcs для генерации запроса и установки сертификата на токен после его получения из УЦ. Полученный ответ меня несколько огорошил:

Прошло время и утилита, начатая как просмотрщик сертификатов, дополненная функциями работы с криптографическими токенами PKCS#11 и создания запросов (PKCS#10) на квалифицированный сертификат, пополнилась, как и было заявлено, функциями работы с контейнерами PKCS#12.


Загружаем, запускаем утилиту cryptoarmpkcs и нажимаем кнопку «PKCS12»:

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

В комментариях к статье «Использование механизмов криптографических токенов PKCS#11 в скриптовых языках» читатель kovserg написал:

«С нетерпением ждём статью с функцией подписания документа и добавлением метки времени».

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

В свое время реализация отечественных криптографических алгоритмов в библиотеке libgcrypt очень меня вдохновила. Стало возможным задействовать эти алгоритмы и в Kleopatra и в Kmail и в GnuPg в целом, рассматривать библиотеку libgcrypt как альтернативу openssl с ГОСТ-ым engine. И все было замечательно до прошлой пятницы.

В своих комментариях к статье «Англоязычная кроссплатформенная утилита для просмотра российских квалифицированных сертификатов x509» пользователь Pas очень правильно заметил про токены PKCS#11, что они «сами все умеют считать». Да, токены фактически являются криптографическими компьютерами. И естественным является желанием использовать эти компьютеры в скриптовых языках будь то Python, Perl или Ruby. Мы уже так или иначе рассматривали использование токенов PKCS#11 с поддержкой российской криптографии в Python для подписания и шифрования документов, для создания запроса на сертификат:

Транспортный синтаксис ASN.1 определяет однозначный способ преобразования значений переменных допустимых типов в последовательность байт для передачи по сети. В ASN.1 он называется базовыми правилами кодирования (Basic Encoding Rules, BER). Правила являются рекурсивными, так что кодирование составных объектов представляет собой составление в цепочку закодированных последовательностей составляющих объектов. Протокол ASN.1 описывает структуру данных простым и понятным языком.

В комментариях к статье «Англоязычная кроссплатформенная утилита для просмотра российских квалифицированных сертификатов x509» было пожелание от пользователя Pas иметь не только «парсинг сертификатов», но и получать «цепочки корневых сертификатов и проводить PKI-валидацию, хотя бы для сертификатов на токенах с неизвлекаемым ключом». О получении цепочки сертификатов рассказывалось в одной из предыдущих статей. Правда там речь шла о сертификатах, хранящихся в файлах, но мы обещали добавить механизмы для работы с сертификатами, хранящимися на токенах PKCS#11. И вот что в итоге получилось.

Сегодня использование цифровых сертификатов X509 v.3 стало обыденным делом. Все больше людей используют их для доступа на сайт Госуслуги, ФНС, электронные торги и т.д. И все больше людей хотят знать, что же находится в этом «сундуке» под названием сертификат. И если сертификат является аналогом паспорта, то как его можно прочитать/просмотреть. Да, в операционных системах присутствуют различные утилиты для просмотра. Но рядовому гражданину они мало что дадут. Возьмем для примера утилиту gcr-viewer, которая, по сути, является стандартным средством для просмотра в Linux-системах, а значит и в отечественных ОС:

Когда мы говорим о дистрибутиве операционной системы, то речь впервую очередь идет не об ядре операционной системы, а о тех приложениях, которые входят в состав дистрибутива. А когда мы говорим об импортозамещение операционных систем, то речь идет о той или иной версии Linux. Ничего другого на российском рынке для импортозамещения не предлагается. Что касается ядра linux, то за его развитие отвечает Ли́нус Бенедикт То́рвальдс. И честно говоря мне ничего неизвестно, про российское ядро linux. А вот окружение любого дистрибутива linux разрабатывается различными организациями, все их и не перечислить: KDE, Mozilla, Google, IBM и т.д. и т.д. И следовало бы ожидать, что с появлением отечественных ОС аля linux этот список будет расширен отечественными разработками или модификациями. Но этого нет. Нет, это не обязательно отечественный браузер или почтовый клиент в этих дистрибутивах. Но что-то доработанное с учетом российских реалий в цифровой экономике хотелось бы видеть. Остановимся на этом.

Пришла пора, несмотря на все пожары, исполнить свой гражданский долг – заплатить налоги. Платить налоги мы будем через портал Госуслуги. В личный кабинет портала Госуслуг будем входить с помощью электронной подписи (терминология портала Госуслуг ), т.е. имея на руках сертификат, полученный в аккредитованном удостоверяющем центре (УЦ), и закрытый ключ. И то и другое я храню на токене PKCS#11 с поддержкой российской криптографии:

26 августа в ближайшем подмосковье, а именно в микрорайоне Юбилейный г. Королев, случился пожар в многоквартирном доме (можно в google набрать «Королев пожар на Ленинской 4»):

Квалифицированные сертификаты быстро стали неотъемлемой частью повседневной жизни. И все больше людей хотят увидеть этого «зверя» изнутри. Это с одной стороны. А с другой стороны разрабатывается все больше приложений, в которых задействуется информация иэ этих сертификатов. И это не только атрибуты ИНН или ОГРН владельца или издателя сертификата. Это может быть и информация о том какой криптопровайдер использован владельцем сертификата (атрибут subjectSignTool) для генерации закрытого ключа или на базе каких сертифицированных средств создан удостоверяющий центр (УЦ), выпустивший тот или иной сертификат. И если написать программку, которая будет анализировать выпускаемые сертификаты, то можно будут собрать интересную статистику по тому какие СКЗИ используют владельцы сертификатов и на базе каких (правда это менее интересно) сертифицированных (или несертифицированных) средств развернуты УЦ (атрибут issuerSignTools):

Неумолимо приближается час «Ч»: «использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается!». И вот, наконец, 16 июля 2018 г. на сайте Федерального ситуационного центра электронного правительства появилось Уведомление о начале выпуска сертификатов ключей проверки электронных подписей подчиненных удостоверяющих центров на головном удостоверяющем центре в соответствии с ГОСТ Р 34.10-2012. Правда, все равно не ясно когда же прекратится выпуск старых сертификатов. Но «процесс пошел» и это радует.

Мы продолжаем разговор об альтернативе openssl и речь пойдет о библиотеке libksba, которая входит в состав GnuPG. Библиотека libksba предоставляет высокоуровневый интерфейс для работы с такими объектами инфраструктуры открытых ключей как сертификаты, запросы на сертификаты, электронная подпись (CMS/PKCS#7). Однако, в отличии от библиотеки GCrypt, в которой реализована поддержка российских криптографических алгоритмов, то в libksba отсутствует реализация рекомендаций ТК-26 по использованию алгоритмов ГОСТ Р 34.10-2001/2012, ГОСТ Р 34.11-94/2012 в таких объектах ИОК как сертификаты, запросы на сертификаты, объекты PKCS#7/CMS (подписанные и/или шифрованные документы и т.п).

В одном из комментариев, присланным участником garex, в ответ на заявление:

Но сегодня в стандартной версии openssl отсутствует поддержка как ГОСТ Р 34.11-2012, так и ГОСТ Р 34.10-2012. Более того в версии 1.1 поддержка криптографии ГОСТ исключена из стандартной поставки («The GOST engine was out of date and therefore it has been removed.»)

было сказано:

Чем не устраивает вот эта, которую «убрали?» github.com/gost-engine/engine
Пример билда: github.com/rnixik/docker-openssl-gost/blob/master/Dockerfile

Приближается вторая половина 2018 года и скоро должен наступить «2000-й год» в ИОК на базе российской криптографии. Это связано с тем, что

использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается!

Уже сегодня не имеет смысла получать сертификаты с подписью по ГОСТ Р 34.10-2001.

Если одним из главных объектов инфраструктуры открытых ключей (ИОК) являются сертификаты X509, то центральным субъектом ИОК являются Удостоверяющие Центры (УЦ). Именно УЦ выпускают сертификаты, прекращают их действие (отзыв сертификата), подтверждают их валидность. На страницах Хабрахабр можно найти различные публикации на тему выпуска цифровых сертификатов с использованием OpenSSL.

Одним из центральных объектом инфраструктуры открытых ключей (Public Key Infrastructure — PKI/ИОК) наряду с ключевой парой является сертификат, который сегодня фактически является аналогом гражданского паспорта.