С появлением библиотеки GCrypt-1.7.0 с поддержкой российской криптографии (ГОСТ 28147-89, ГОСТ Р 34.11-94/2012 и ГОСТ Р 34.10-2001/2012), стало возможным говорить о поддержке российского PKI в таких проектах как Kleopatra и KMail.

KMail – это почтовый клиент, который для обеспечения безопасности переписки позволяет подписывать и шифровать сообщения по протоколу S/MIME. И то и другое базируется на архитектуре PKI, сертификатах X509 и протоколах CMS/PKCS#7:

В настоящей статье описывается процесс настройки двухфакторной аутентификации по смарт-картам и USB-токенам JaCarta PKI на основе цифровых сертификатов X.509 в OpenVPN.

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

Название статьи подсказала тема на одном из форумов. Несмотря на то, что с момента возникновения вопроса прошло шесть лет, в этом направлении мало что изменилось. А поскольку в последнее время у меня на слуху постоянно был OpenVPN, то было решено исправить данную ситуацию. Так родилась графическая утилита VpnGUI для создания, редактирования, запуска и контроля выполнения утилиты openvpn.

После запуска утилиты VpnGUI в трее появится иконка (квадрат разбитый на четыре сине-красных квадратика) утилиты:

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

В одном из комментариев, присланным участником 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

Неделю назад состоялся релиз свободной библиотеки для генерации pdf-файлов версии OpenPDF 1.1.0, самый значительной апгрейд этой библиотеки за последнее время.

OpenPDF — это Java-библиотека для создания и редактирования файлов PDF, которая распространяется под двойной лицензией LGPL/MPL. Библиотека основана на форке iText. В реальности у неё такая история:

LibrePDF/OpenPDF

forked from rtfarte/OpenPDF

forked from kulatamicuda/iText-4.2.0

forked from daviddurand/iText-4.2.0

forked from ymasory/iText-4.2.0

Все форки ведут историю от одной версии iText 4.2.0, которая вышла восемь лет назад и стала последней версией под свободной лицензией. Сами разработчики iText перешли на AGPL и сконцентрировались над созданием пятой версии, чтобы более успешно продавать коммерческий софт. К настоящему времени они доросли до версии iText 7. Но свободный проект тоже не погиб, а продолжил развитие силами всего сообщества.

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

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


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

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

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

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

Вот мы и добрались до создания самоподписанных сертификатов.
Где применяются самоподписанные сертификаты? Конечно, с самоподписанным сертификатом вы не сможете зарегистрироваться на сайте Госуслуг или подать подписанную декларацию в ФНС. Но для внутрикорпоративного документооборота их вполне можно использовать. Можно также использовать их для защиты личной почтовой переписки, в VPN-сетях и т.п. Но наиболее часто используют самоподписанные SSL-сертификаты для обеспечения защищенного доступа по https-протоколу к Web-приложениям. Самым популярным средством для создания самоподписанных сертификатов остается OpenSSL. Процедура получения SSL-сертификатов с помощью того же OpenSSL хороша описана здесь. Но там вы не найдете упоминая о ГОСТ-овых сертификатах, о токенах PKCS#11 и т.п. Здесь мы рассмотрим простой графический интерфейс, который позволяет получать сертификаты на базе ГОСТ Р 34.10-2012 и без всякого использования OpenSSL.

Основной работой при создании утилиты cryptoarmpkcs было не разработка кода или графического интерфейса, а работа с ASN1-структурами. Именно в этих структурах хранятся сертификаты x509v3, электронные подписи документов (PKCS#7, CMS), запросы на сертификаты (PKCS#10, CSR), открытые и закрытые ключи, защищенные контейнеры PKCS#12/PFX, списки отозванных сертификатов CRL и штампы времени для электронной подписи, запросы и ответы OCSP и так далее и тому подобное. Постоянно приходилось просматривать уже имеющиеся структуры для понимания того как это делали другие, просматривать только что собранные самим AN1-структуры. Процесс понятен. Но поскольку я работаю на Linux (сейчас это Mageia, и код для Windows тоже готовлю на Linux), то под рукой из доступных средств разбора ASN1-структур были утилиты openssl и derdump из пакета NSS. Лично мои предпочтения были на стороне derdump. Именно она и стала прототипом рассматриваемой здесь утилиты derdump.tcl/tclderdump для просмотра ASN1-структур. И если вы сравните вывод утилиты derdump из пакета NSS и утилиты derdump.tcl, то вы практически не увидите различий:

Еще раз просмотрев функционал утилиты cryptoarmpkcs, обратил внимание на то, что она, в основном работая с криптографическими токенами/смаркартами PKCS#11, не имеет встроенного функционала для их конфирурирования. Речь идет об инициализации токенов, установки PIN-кодов и т.п. И было решено добавить этот функционал. Первым делом для этого пришлось расширить функционал пакета TclPKCS11, библиотека которого написана на языке Си.

Новые функции пакета TclPKCS11

В пакете появились три новые функции:

::pki::pkcs11::inittoken <handle> <slotId> <SO-pin> <label for token>

::pki::pkcs11::inituserpin <handle> <slotId> <SO-pin> <USER-pin>

::pki::pkcs11::setpin <handle> <slotId> <so | user> <oldpin> <newpin>

Пришло время продемонстрировать как криптографический АРМ на базе стандартов с открытым ключом cryptoarmpkcs работает на одной из мобильных платформ, а именно Android.

Концепция, которая закладывалась при разработке утилиты cryptoarmpkcs, состоит в том, что пользователь должен испытывать минимум неудобств при создании и проверке электронной подписи. Именно поэтому мы предлагаем в качестве ключевого носителя для личного сертификата использовать криптографические токены PKCS#11 и/или защищенные контейнеры PKCS#12. Надо сказать, что использование PKCS#12 во многих случаях оказывается чуть ли не единственно возможным, например, когда у тех же токенов PKCS#11 не оказывается поддержки для тех или иных платформах.

Подошло время задействовать криптографические механизмы PKCS#11 и на платформе Android. Кто-то может сказать, что нет аппаратных токенов для Android. Но, если это и так, то это только временное явление. Но уже сегодня можно поставить программный токен или использовать облачный токен. Поскольку утилита cryptoarmpkcs-A разрабатывается для платформы Android с использованием Androwish на скриптовом языке Tcl/Tk, то для подключения токенов используется пакет TclPKCS11 версии 1.0.1.

При этом никакой переработки пакета не потребовалось. Все что было сделано, это был добавлены в проект скрипт для сборки библиотеки пакета, написанной на языке Си, под Android и сам дистрибутив библиотеки. В этот же проект было решено добавить и библиотеки программного ls11sw2016 и облачного ls11cloud токенов для различных платформ.

С точки зрения PKCS#11 интерфейса, использование облачного токена не отличается от использования аппаратного токена. Для использования токена на компьютере (а у нас пойдет речь о платформе Android) необходимо иметь библиотеку для работы с токеном и собственно подключенный токен. Для облачного токена нужно тоже самое — библиотеку и подключение к облаку. В качестве такого подключения выступает некий конфигурационный файл, в которой прописывается адрес облака, в котором хранятся токены пользователей.

Проверка статуса криптографического токена

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



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

Регистрация облачного токена

Переходим на вкладу «Подключение Токенов PKCS#11», находим пункт «Создание облачного токена» и скачиваем приложение LS11CloudToken-A

Инфраструктура открытых ключей (PKI/ИОК) включает в себя множество различных объектов и механизмов работы с ними, а также протоколы взаимодействия объектов друг с другом (например, протоколы TLS, OCSP). В число объектов ИОК входят запросы на сертификаты (PKCS#10) и сами сертификаты x509, ключевые пары (приватные и публичные ключи), подписанные и зашифрованные документы (PKCS#7, CMS), защищенные контейнеры для хранения приватных ключей (PKCS#8) и личных сертификатов с ключами (PKCS#12) и т.д. В число механизмов входят не только криптографические функции, которые позволяют шифровать и подписывать документы по различным алгоритмам, но и функции, формирующие конечные объекты ИОК в соответствии со стандартами (сертификаты, запросы, подписанные/зашифрованные документы, пакеты протоколов и т.д. и т.п.). Да и как не вспомнить центральный объект ИОК/PKI — УЦ.

Сегодня уже трудно представить деловую жизнь страны без ИОК, без сертификатов x509 (без квалифицированных сертификатов), без сервисов ГОСУСЛУГИ и ФНС, где документы принимаются в электронном виде с электронной подписью. И все больше документов возвращаются к гражданину тоже в электронном виде с электронной подписью. Судопроизводство уже также невозможно представить без электронной подписи.

7 сентября 2021 года мне пришло электронное письмо:

fsb795
Добрый день.
не планируете библиотеку подправить под свежие изменения в приказе 795 ?

Было понятно, что речь идет о пакете fsb795, написанном на Python для разбора квалифицированных сертификатов. Требования к составу и форме квалифицированного сертификата установлены Приказом ФСБ России от 27.12.2011 №795. Но 29 января 2021 года в этот приказ были внесены изменения. Именно об этих изменениях мне и напомнил автор письма. Письмо я получил 7 сентября, а изменения вступили в силу 1-го сентября 2021 года. В этот период времени я был увлечён написанием статьи, связанной с пятидесятилетием окончания Казанского суворовского военного училища и выбора мною стези программиста: