Инфраструктура открытых ключей: утилита генерации запросов на квалифицированный сертификат

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

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

Сертификат, также как и паспорт, выдается на основании заявления и предоставления ряда документов. Перечень документов для получения сертификата есть на любом удостоверяющем центре, имеющим аккредитацию Минкомсвязи (новое название — министерство цифрового развития, связи и массовых коммуникаций). Заявление на паспорт имеет собственноручную подпись заявителя. В момент получения паспорта заявитель поставит свою подпись и в паспорт, которая будет заверена сотрудником паспортного стола и гербовой печатью. Фотография и умение владельца воспроизводить свою подпись и позволяют идентифицировать его как владельца конкретного паспорта.

По аналогичной схеме происходит и получение сертификата ключа проверки электронной подписи (СКПЭП). Сначала гражданин, желающий получить сертификат, должен приобрести «навык» в проставлении собственноручной подписи. Этот «навык» реализуется через получение заявителем ключевой пары, которая содержит открытый ключ или ключ проверки электронной подписи (КПЭП) и закрытый ключ или ключ электронной подписи, который, собственно, и позволяет генерировать электронную подпись и подписывать электронный документ. Идентификация электронной подписи под документом осуществляется по следующему алгоритму. Из сертификата определяется каким ключом (ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012 с длиной ключа 64 или 128 байт) был подписан документ. По типу ключа определяется алгоритм хэширования, который использовался при подписании документа. Это может быть ГОСТ Р 34.11-94 или ГОСТ Р 34.11-2012 с длиной хэш 256 или 512 бит. По выбранному алгоритму считается хэш от исходного документа. А по значению посчитанного хэш от исходного документа, публичного ключа (КПЭП) и его параметрам (все это берется из сертификата СКПЭП) и проверяется достоверность электронной подписи под документом.

Для создания ключевой пары используются различные средства криптографической защиты информации (СКЗИ), поддерживающие криптографические алгоритмы ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012. При этом следует помнить, что использование схемы подписи ГОСТ Р 34.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.

Хотелось бы упомянуть еще об одной утилите, а именно о tcl2c. Эта утилита «заварачивает» tcl/tk-код в C-код.

Для получения исполняемого кода достаточно выполнить команду:

$cc -o create_csr_С create_csr.c -ltcl -ltk
$

В состав дистрибутивов для платформы Linux включен и дистрибутив на языке С со статическим подключением пакета cwapi.
  • +15
  • 3,9k
  • 9
Поделиться публикацией
Комментарии 9
    0
    Резкий переход в конце статьи от пошагового описания элементарных операций, приправленного скриншотами, к исходникам способен взорвать мозг.
      0

      Не совсем понял. Элементарные операции "приправленные" скриншотами как раз и позволяют ориентироваться в исходном коде. Дистрибутив с исходным кодом можно взять здесь.

        +1
        Извините, если неясно выразился. Начало статьи изложено в стиле, ориентированном на пользователя, далекого от IT, что крайне резко контрастирует с окончанием статьи. Пришлось даже возвращаться назад и вчитываться — не пропустил ли я кусок текста.
          0

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

            +1
            А мне интерфейс понравился
              0
              Я же вовсе не критиковал интерфейс, я писал про саму статью, если точнее, то про резкую смену стиля изложения в конце, об которую «спотыкаешься» при чтении.
                0

                Я это понял. Спасибо.

        +1
        {Госуслуги} {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-ы ИНН, ОГРН, СНИЛС и т.п., которые однозначно идентифицируют и физическое лицо и юридическое лицо и, кажется, этого было бы достаточно для доступа на портал Госуслуг, да и на другие тоже. Но, Dura lex, sed lex — Закон суров, но это закон.
        Некоторые гос. системы требуют наличия в сертификате определенных полномочий. Часть могу расшифровать:
        1.3.6.1.4.1.311.20.2.2 Вход в систему с помощью смарт-карты
        1.2.643.100.2.1 СМЭВ. Уполномоченное лицо для подписания электронных документов при межведомственном взаимодействии
        1.3.6.1.5.5.7.3.2 Работа с ГМУ (Аутентификация клиента)
        1.3.6.1.5.5.7.3.4 Защита электронной почты
          +1

          Да, вы правы. Можно "расшифровать" и другие. Речь немного о другом. Мне как гражданину или юридическому лицу, которые имеею ИНН, ИНИЛС, ОГРН, которые однозначно определяют субъекта, для доступа к тем же Госуслугам по большому счету больше ничего не надо. А так у нас все автоматом становятся "Уполномоченными лицами для подписания электронных документов при межведомственном взаимодействии" и т.п. Зачем все это? У нас и так много смешного в этой области. Но, все равно спасибо.

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

        Самое читаемое