[Из песочницы] Инфраструктура открытых ключей: утилита генерации запросов на квалифицированный сертификат
Одним из центральных объектом инфраструктуры открытых ключей (Public Key Infrastructure — PKI/ИОК) наряду с ключевой парой является сертификат, который сегодня фактически является аналогом гражданского паспорта.
Имея на руках сертификат, гражданин может получить доступ к порталу Госуслуг, заплатить налоги, защитить свою электронную почту, подписывать и шифровать документы и многое другое.
Перечень документов для получения сертификата есть на любом удостоверяющем центре, имеющим аккредитацию Минкомсвязи (новое название — министерство цифрового развития, связи и массовых коммуникаций). Сертификат, также как и паспорт, выдается на основании заявления и предоставления ряда документов. В момент получения паспорта, заявитель поставит свою подпись и в паспорт, которая будет заверена сотрудником паспортного стола и гербовой печатью. Заявление на паспорт имеет собственноручную подпись заявителя. Фотография и умение владельца воспроизводить свою подпись и позволяют идентифицировать его как владельца конкретного паспорта.
Сначала гражданин, желающий получить сертификат, должен приобрести «навык» в проставлении собственноручной подписи. По аналогичной схеме происходит и получение сертификата ключа проверки электронной подписи (СКПЭП). Идентификация электронной подписи под документом осуществляется по следующему алгоритму. Этот «навык» реализуется через получения заявителем ключевой пары, которая содержит открытый ключ или ключ проверки электронной подписи (КПЭП) и закрытый ключ или ключ электронной подписи, который собственно и позволяет генерировать электронную подпись и подписывать электронный документ. 10-2001, ГОСТ Р 34. Из сертификата определяется каким ключом (ГОСТ Р 34. По типу ключа определяется алгоритм хэширования, который использовался при подписании документа. 10-2012 с длиной ключа 64 или 128 байт) был подписан документ. 11-94 или ГОСТ Р 34. Это может быть ГОСТ Р 34. По выбранному алгоритму считается хэш от исходного документа. 11-2012 с длиной хэш 256 или 512 бит. А по значению посчитанного хэш от исходного документа, публичного ключа (КПЭП) и его параметрам (все это берется из сертификата СКПЭП) и проверяется достоверность электронной подписи под документом.
10-2001 и ГОСТ Р 34. Для создания ключевой пары используются различные средства криптографической защиты информации (СКЗИ), поддерживающие криптографические алгоритмы ГОСТ Р 34. При этом следует помнить, что использование схемы подписи ГОСТ Р 34. 10-2012. СКЗИ, которые реализуют различнык криптографические алгоритмы и протоколы могут быть как программными, так и аппаратными. 10-2001 для формирования подписи после 31 декабря 2018 года не допускается! Абсолютное большинство сертифицированных СКЗИ с российской криптографией поддерживает либо универсальный криптографический интерфейс PKCS#11, который поддерживается на всех платформах, либо интерфейс CSP и CryptoAPI от Микрософт на платформах MS Windows (далее MS CSP). Доступ к СКЗИ осуществляется через криптографические интерфейсы. Именно эти два типа СКЗИ и будут рассматриваться далее: Именно эти два криптографических интерфейса и поддерживаются, например, порталом Госуслуг.
Следует иметь ввиду, что если есть желание или необходимость работы с электронной подписью не только на платформе Windows, но и на других платформах (Linux, macOS и т.п.), то следует выбирать токены PKCS#11 с поддержкой российской криптографии.
Помимо основной функции, связанной с генерацией запроса, в утилите предусмотрены функции для работы с токенами и сертификатами:
Комбинированное поле (combobox) «Выберите токен:» на основном окне содержит список доступных СКЗИ для генерации ключевой пары. Если утилита генерации запроса запущена на платформе Windows и на ней установлены криптопровайдеры CSP с поддержкой российской криптографии, то в перечне доступных СКЗИ («Выберите токен:») будет определен и виртуальный токен «MS_CSP». Так что, если есть желание использовать криптопровайдер MS CSP, то он должен быть установлен в системе до запуска утилиты.
Добавление поддержки для нового токена состоит в выборе библиотеки PKCS#11 для подключаемого типа токенов/смарткарт и задании удобного имени (никнайма). Для добавления поддержки нового токена PKCS#11 достаточно выбрать пункт меню «Управление Токенами->Добавить Токен». При добавлении поддержки нового типа токенов (а также при запуске утилиты, если ранее была добавлена поддержка токенов) при подключенном (вставленном) токене будет затребован PIN-код для доступа к нему:
Но это произойдет только в том случае, если токен не только подключен, но и находится в рабочем состоянии, т.е. проинициализирован. Проверить токен и, при необходимости, проинициализировать его, сменить PIN-код для доступа к нему и т.д. удобно утилитой p11conf :
Выбрав пункт «Управление Токенами->Механизмы Токена» можно посмотреть криптографические механизмы того или иного токена, например, есть ли поддержка алгоритма ГОСТ Р 34.10-2012. Для виртуального токена MS_CSP перечисляются все провайдеры CSP с поддержкой ГОСТ-алгоритмов и поддерживаемые ими механизмы:
Если выбранный токен не поддерживает выбранный тип ключевой пары, то будет выдано соответствующее сообщение:
Прежде чем перейти непосредственно в заполнению полей запроса необходимо определиться для каких целей нужен сертификат, т.е. указать «Роль сертификата». Сегодня таких ролей накопилось ни один десяток:
И каждая роль связанна со множеством различных OID-ов, включаемых в сертификат. Так, например, для доступа на портал Госуслуг, необходимы следущие oid-ы:
{clientAuth, emailProtection, 1.3.6.1.4.1.311.20.2.2, 1.2.643.100.2.1, 1.2.643.2.2.34.6, 1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4, 1.2.643.5.1.24.2.1.3, 1.2.643.6.14, 1.2.643.3.215.4, 1.2.643.3.215.5, 1.2.643.3.215.6, 1.2.643.3.215.7, 1.2.643.3.215.8, 1.2.643.3.215.9, 1.2.643.3.215.11, 1.2.643.3.215.12, 1.2.643.3.215.13, 1.3.6.1.4.1.40870.1.1.1, 1.2.643.2.64.1.1.1, 1.2.643.3.5.10.2.12, 1.2.643.6.3.2, 1.2.643.5.1.24.2.46, 1.2.643.6.45.1.1.1, 1.2.643.5.1.24.2.30, 1.2.643.5.1.28.2, 1.2.643.5.1.28.3, 1.2.643.3.202.1.8}
OID-ы для других ролей (например, «Площадка Газпромбанк», «Потребитель спирта» и т.д.) можно найти в исходном коде утилиты (переменная oid_roles_bad, оператор
set oid_roses_bad {. . .}
Наличие такого количества oid-ов трудно понять. Речь идет о квалифицированных сертификатах, в которых присутствуют oid-ы ИНН, ОГРН, СНИЛС и т.п., которые однозначно идентифицируют и физическое лицо и юридическое лицо и, кажется, этого было бы достаточно для доступа на портал Госуслуг, да и на другие тоже. Но, Dura lex, sed lex — Закон суров, но это закон.
В последующем значение этого поля войдет в сертификат. В поле «Наименование СКЗИ» необходимо указать название СКЗИ (токен/смарткарта, CSP), которое прописано в сертификате соответствия (не путать с сертификатом X509) ФСБ России или другом аналогичном документе, копию которого должна предоставляться в момент приобретения СКЗИ.
И так, определившись со СКЗИ и ключевой пары, можно приступать к заполнению электронного заявления/запроса на сертификат ключа проверки электронной подписи (СКПЭП):
Первым заполняется поле «Common Name», в которое заносится полное имя будущего владельца сертификата. Для физического лица это ФИО как в паспорте. Для юридического лица это наименование компании из ЕГРЮЛ. Эта информация для юридического лица автоматически будет продублирована в поле «Наименование организации» («O»):
При заполнении формы проверяется правильность заполнения полей ИНН, ОГРН, СНИЛС (при вводе не цифры поле становится красным, правильно заполненные поля становятся зеленоватыми), адреса электронной почты:
После заполнения всех полей запроса и нажатия кнопки «Finish» в итоге будет получен запрос на сертификат:
В процессе создания запроса будет сгенерирована ключевая пара на выбрпанном токене. При этом, если в качестве токена выбран виртуальный токен «MS_CSP», который, в свою очередь, поддерживает различные носители для хранения ключевой пары, будет предложено выбрать еще и конкретный носитель:
Напомним, что ключевая пара содержит два ключа: закрытый и открытый. Открытый ключ, который еще называют ключом проверки электронной подписи, отправляется в запрос на сертификат. Для просмотра сгенерированного запроса, который содержит и открытый ключ, используется меню «Сертификаты->Просмотр запроса»:
Закрытый ключ остается у заявителя на его токене, PIN-код (пароль) от которого необходимо хранить как зеницу ока Своего. А поскольку существует однозначное соответствие между открытым и закрытым ключами, то можно всегда проверить кому принадлежит запрос на сертификат, а в дальнейшем и сам сертификат, подпись под документом и т.д.
И так запрос поступает для выпуска сертификата в один из УЦ, созданных с учетом Федерального закона от 6 апреля 2011г. Теперь со всеми необходимыми документами, со сгенерированным запросом на флэшке можно идти в ближайший удостоверяющий центр и получать сертификат. №63-ФЗ «Об электронной подписи»:
Запрос в УЦ пройдет стадии импорта, рассмотрения, утверждения и выпуска сертификата по данному запросу:
Выпущенный сертификат будет опубликован на одном из сервисов УЦ, откуда его можно будет скачать. А сейчас достаточно, чтобы выпущенный сертификат был экспортировали на флэшку заявителя:
И вот теперь, когда получен сертификат, осталось положить его на СКЗИ (PKCS#11, MS CSP) (Сертификаты->Импорт x509):
Убедиться, что сертификат находится на токене, можно просмотрев содержимое токена/смарткарты (Сертификаты->Просмотр x509 на токене):
Ну и чтобы это была «броня» (Дайте мне такую БУМАЖКУ! Окончательная Бумажка, Броня. (Собачье Сердце к/ф)), подключим токен к браузеру Firefox с поддержкой российской криптографии, и найдем выпущенный сертификат в личных сертификатах (в числе таких сертификатах, для которых на токене имеется закрытый ключ):
Утилита CreateCSRCAFL63 разработана на Tcl/Tk. Для доступа к криптографическим функциям MS CSP и токенов PKCS#11 разработан пакет cwapi, реализующий требования к библиотекам C со стороны Tcl. Реализовать эти требования не сложно, но порой отнимает много времени в силу своей рутинности. И тут на помощь приходит общедоступная утилита SWIG., которая позволяет создавать интерфейсные модули между библиотеками C/C++ и другими языками. Это не только Tcl, но и Java и другие. Проект очень хорошо документирован и имеет прекрасные примеры. Воспользоваться им не представляет труда. В нашем случае для получения интерфейсного модуля был написан простой исходный файл cwapi.i для утилиты swig:
%module cwapi
%inline %{
#include "cwapi.h"
%}
%include "cwapi_SWIG.h"
В файл cwapi.h находятся описания функций из основного проекта cwapi:
#ifdef __cplusplus
extern "C" {
#endif int CW_Initialize (char *configdir); int CW_Finalize (); int addp11mod (char *nickname, char *library); int remp11mod (char *nickname); char * lmod (); char * ltok (); char * lcert (char *token, int priv_cert); char* createreq (char *token, char *subject, char *keyusage, int keyparams, int pem, char *skzi, char* role); char* viewx509 (char *nickname, int CertOrReq); char* x509pem (char *nickname); char* x509fromfile(char *token, char *infile, char *trusts); int delcert (char *nickname, int priv_cert); int p12tofile (char *token, char *nickname, char *outfile); char* p12fromfile(char *token, char *infile); char* lmech(char* token); char* tinfo(char* token);
#ifdef __cplusplus
}
#endif
Выполнив команду:
$export SWIG_LIB=/usr/local/swig-3.0.12/Lib $/usr/local/swig-3.0.12/swig -tcl8 -o cwapi_wrap.c cwapi_.i
$
в файле cwapi_wrap.c получим готовый интерфейсный модуль. Добавляем его в проект cwapi, пересобираем его и получаем новый пакет, который и используется в данной утилите.
Для получения дистрибутива очень удобно использовать утилиту freewrap, при этом библиотека cwapi также включается в непосредственно в дистрибутив. Исходный код утилиты и дистрибутивы доступны для платформ Windows и Linux.
Эта утилита заварачивает tcl/tk-код в C-код. Хотелось бы упомянуть еще ою одной утилите, а именно о tcl2c.
Для получения исполняемого кода достаточно выполнить команду:
$cc -o create_csr_С create_csr.c -ltcl -ltk
$
В состав дистрибутивов для платформы Linux включен и дистрибутив на языке С со статическим подключением пакета cwapi.