Механизмы аутентификации и подтверждения платежа посредством электронной подписи широко применяются в системах ДБО. Эволюция технических средств электронной подписи наглядно показана в статье Щит и меч в системах ДБО. Кратко линейку можно представить в виде — токены, токены с криптографией на борту, trustscreen с криптографией на борту.

Обычно устройства с криптографией на борту реализуют базовые криптографические алгоритмы — ЭП, хэш-функцию, шифрование. Но в ряде случаев в системах ДБО для аутентификации и ЭП применяются цифровые сертификаты. Для интеграции криптографических возможностей устройств и инфраструктуры PKI мы выпустили решение Рутокен WEB PKI Edition, мультиплатформенный и мультибраузерный плагин для систем с web-интерфейсом.



Новая версия плагина поддерживает наш trustscreen с криптографией на борту — устройство Рутокен PINPad. Теперь можно проверить, что подписывается действительно платежка, отображаемая в браузере.

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

Некоторое время назад мы поддержали Рутокен ЭЦП в openssl, затем выпустили кроссплатформенный плагин для браузера, а теперь сделали высокоуровневую криптобиблиотеку для встраивания в С++ приложения.

Концептуально данные решения выполнены идентично: используется аппаратная реализация российских криптоалгоритмов на чипе Рутокен ЭЦП, обеспечивается поддержка цифровых сертификатов X.509, запросов на сертификаты PKCS#10, подписанных и зашифрованных сообщений CMS.

Новая библиотека пригодится тем, кто пишет «толстые клиенты», десктопные приложения, свои браузерные плагины и т.п.

Поддерживаемые устройства:

• USB-токен Рутокен ЭЦП
• Смарт-карта Рутокен ЭЦП
• Bluetooth-токен Рутокен ЭЦП
• Trustscreen-устройство Рутокен PINPad
• USB-токен Рутокен WEB (HID)

Основные сценарии применения библиотеки с примерами кода под катом.

Флагманским продуктом нашей компании является Рутокен ЭЦП — устройство с российской криптографией «на борту». Для интеграции устройства с браузерами был выпущен Рутокен Плагин. Демонстрацию возможностей плагина можно посмотреть на тестовых площадках. Некоторые из них предполагают работу с цифровыми сертификатами, хранящимися на устройствах. Например, Демо-банк при регистрации пользователей выписывает пользовательский сертификат, а при логине в систему запрашивает его и проверяет. Для реализации данных задач на сервере используется библиотека BouncyCastle.


В данной статье будут рассмотрены примеры ее использования для выписки сертификатов по запросу PKCS#10, а также для проверки подписи CMS, выработанной по российским криптоалгоритмам.

С появлением библиотеки 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:

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

Если одним из главных объектов инфраструктуры открытых ключей (ИОК) являются сертификаты 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

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

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

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

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

В первой части нашего повествования мы показали как, имея на руках криптографический токен с поддержкой российской криптографии, создать запрос на получение сертификата, получить и установить сертификат на токен, проверить электронную подпись сертификата и его валидность по списку отозванных сертификатов (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

Как все начиналось

В самом начале периода самоизоляции мне на почту пришло письмо:



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

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

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