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



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



И Kleopatpa и KMail не имеют встроенной криптографии: все криптографические преобразования для них делает их свита и прежде всего модуль gpgsm из пакета GnuPg. Для криптографических вычислений используется библиотека LibGCrypt. А для разбора сертификатов X509, подписанных или зашифрованных сообщений (CMS/PKCS#7, PKCS#10 и т.п.) используется библиотека libksba. Упомянем еще библиотеку libgpgme, но о ее роли чуть позже.

И если сама Kleopatpa и ее верный слуга KMail ничего против российской криптографии не имеют, то их свита, за исключением LibGCrypt, наотрез отказывается с ней дружить.

Начнем с самого безобидного члена свиты, а именно с библиотеки libgpgme. Для начала посмотрим исходный код подписанного сообщения:



В поле «Content-Type» есть переменная micalg, в которой указывается тип хэша, используемого при формировании или проверке подписи. Для многих почтовых клиентов, в том числе и для KMail, отсутствие значение в этом поле никак не влияет на проверку электронной подписи, но только не для Thunderbird и Seamonkey. Поэтому желательно, чтобы это поле и KMail-ом заполнялось. Тем более, что для этого потребуются минимальные усилия. Все, что необходимо это добавить в файл gpgme.h.in номера российских хэш-алгоритмов:

/* Hash algorithms (the values match those from libgcrypt).  */
typedef enum
  {
    GPGME_MD_NONE          = 0,
	.  .  .
    GPGME_MD_CRC24_RFC2440 = 304,
/*Добавлено from gcrypt.h.in  !!!!*/
    GPGME_MD_GOSTR3411_94  = 308, /* GOST R 34.11-94 */
    GPGME_MD_STRIBOG256    = 309, /* GOST R 34.11-2012, 256 bit.  */
    GPGME_MD_STRIBOG512    = 310,  /* GOST R 34.11-2012, 512 bit.  */
    GPSME_MD_GOSTR3411_CP   = 311 , /* GOST R 34.11-94 with CryptoPro-A S-Box.  */  }
gpgme_hash_algo_t;

Причем эти номера должны строго коррелировать с соответствующими номерами из файла gcrypt.h.in библиотеки libgcrypt:

/************************************
*   Cryptograhic Hash Functions    		*
************************************/

/* Algorithm IDs for the hash functions we know about. Not all of them
   are implemented. */
enum gcry_md_algos
  {
    GCRY_MD_NONE    = 0,
    	.   .   
    GCRY_MD_TIGER2        = 307, /* TIGER2 variant.   */
/*Российские хэш алгоритмы*/
    GCRY_MD_GOSTR3411_94  = 308, /* GOST R 34.11-94.  */
    GCRY_MD_STRIBOG256    = 309, /* GOST R 34.11-2012, 256 bit.  */
    GCRY_MD_STRIBOG512    = 310, /* GOST R 34.11-2012, 512 bit.  */
    GCRY_MD_GOSTR3411_CP  = 311, /* GOST R 34.11-94 with CryptoPro-A S-Box.  */
    	.    .   .
    GCRY_MD_SHAKE256      = 317
  };

Вот и все, библиотека libgpgme встала на сторону российской криптографии.

Основная доработка пришлась на GnuPg (модуль gpg-protect-tool), который отвечает, в частности, за импорт личных сертификатов X509 из защищенного контейнера PKCS#12, модуль gpgsm, который в частности, отвечает за формирование и разбор сертификатов, подписанных и зашифрованных сообщений (CMS, PKCS#7) и его подмастерье библиотеку libksba.

Риторический вопрос – где взять личный сертификат, т.е. сертификат X509 и закрытый ключ? Но сегодня с этим вопросов нет, конечно в Удостоверяющем Центре (УЦ). Сегодня в России зарегистрированных только в Минкомсвязи не одна сотня УЦ. Однако надо помнить, что это услуга платная! Для тестирования (и даже внутрикорпоративного защищенного документооборота, включая почтовую переписку) личные сертификаты в защищенном контейнере PKCS#12 можно получить с помощью утилиты openssl, либо на одном из бесплатных тестовых УЦ. Здесь же можно получить личный сертификат сразу в контейнере PKCS#12.

Для импорта личного сертификата в среду Клеопатры (правильнее сказать в хранилище сертификатов и закрытых ключей в GnuPg) необходимо имеющийся личный сертификат выгрузить (экспортировать) в контейнер PKCS#12. При этом может оказаться, что контейнер был сформирован в соответствии с требованиями ТК-26. В настоящее время (подчеркиваем, в настоящее время) GnuPg не ладит с контейнерами PKCS#12 сформированными по требованиям ТК-26, но это и не страшно. Имея под рукой утилиту openssl (а еще лучше утилиту lirssl), мы быстро избавляемся от этого недостатка, выпустив новый контейнер с помощью простого скрипта:

#cat CONVERT_P12_for_GPGSM.sh

# в файле /etc/ssl/openssl.cnf должен быть подкючен ГОСТ-ый engine
export OPENSSL_CONF=/etc/ssl/openssl.cnf
openssl pkcs12 -in $1.p12 -nodes -out $1.txt.p12 -nomacver
openssl pkcs12 -export -in $1.txt.p12 -nodes -out $1\_openssl_cert_key.p12
rm –f 	$1.txt.p12
echo "Файл для импорта в GPGSM: $1\_openssl_cert_key.p12"
#

#sh CONVERT_P12_for_GPGSM.sh фт-2001-2016
Enter Import Password:
Enter Export Password:
Verifying - Enter Export Password:
Файл для импорта в GPGSM: фт-2001-2016_openssl_cert_key.p12
#

Теперь у нас есть контейнер PKCS#12, который мы и будем импортировать:



После нажатия кнопки «Открыть» будет предложено ввести пароль для разбора контейнера PKCS#12:



А затем будет предложено ввести и подтвердить пароль, по которому будет осуществляться доступ к закрытому ключу импортированного сертификата:



Все, личный сертификат импортирован. Сторонние сертификаты, а также корневые сертификаты, импортируются как из формата DER, так и формата PEM.

Теперь, когда Kleopatra владеет сертификатами, она может своим личным сертификатом подписывать документы:



вводя пароль для доступа к закрытому ключу:



Конфиденциальные файлы теперь можно шифровать с использованием сертификата получателя:



При создании CMC/PKCS#7 с шифрованием для формирования ключа шифрования ключей (КЕК) с помощью закрытого ключа, соответствующего ключу originatorKey publicKey, и открытому ключу получателя, применяется алгоритм VKO GOST R 34.10-2012. К сожалению, в текущей версии GCrypt отсутствует реализация данного алгоритма. Реализация данного алгоритма была заимствована из библиотеки LCC-2016 и добавлена в файл ecc-gost.c.

И так, смело нажимаем кнопку «Продолжить»:



Что касается почтового клиента KMail, то для того, чтобы защитить переписку (электронная подпись, шифрование), прежде всего надо выбрать личный сертификат (сертификат, у которого есть закрытый ключ), которым вы будете подписывать почтовые сообщения, а также сертификат, который будет участвовать в шифровании писем:



Нажмите кнопку «Запустить диспетчер сертификатов»: к вашим услугам будет Клеопатра и вы сможете подробно просмотреть свойства выбираемого сертификата.

Теперь можно как подписывать, так и шифровать почтовые сообщения:



После нажатия «Отправить» KMail запросит подтвердить факт шифрования:



И запросит ввести пароль для доступа к закрытому ключу:



Но хочется большего. Речь идет об использовании программно-аппаратных токенов PKCS#11 с поддержкой все той же российской криптографии. Для подключения тоненов PKCS#11 необходимо установить в систему доработанный модуль gnu-pkcs11-scd, а в конфигурационный файл gpg-agent.conf добавить следующие строки:

scdaemon-program /usr/local/bin64/gnupg-pkcs11-scd
pinentry-program /usr/bin/pinentry-qt

После этого необходимо в конфигурационном файле gnu-pkcs11-scd.conf указать библиотеки PKCS#11 для токенов, которые будут использоваться:

#В примере предполагается использование программно-аппаратного токена #LS11USB2016
#с библиотекой /usr/local/lib64/libls11usb2016.so
…
# Comma-separated list of available provider names. Then set
# attributes for each provider using the provider-[name]-attribute
# syntax.
providers libls11usb2016
provider-libls11usb2016-library /usr/local/lib64/libls11usb2016.so
provider-libls11usb2016-cert-private
…

Убедитесь, что gpg-agent запущен:

$ gpg-agent --daemon --use-standard-socket
GPG_AGENT_INFO=/home/a513/.gnupg/S.gpg-agent:19092:1; export GPG_AGENT_INFO;
$

Теперь после запуска Kleopatra или KMail, будет запрошен PIN-код для доступа к токену:



Проверить имя токена, можно воспользовавшись свободно распространяемой утилитой p11conf :

$ /usr/local/bin64/p11conf  -A /usr/local/lib64/libls11usb2016.so -h
usage:  /usr/local/bin64/p11conf [-hitsmIupPred] -A APIpath [-c slotID -U userPin -S SOPin -n newPin -L label]
        -h display usage
        -i display PKCS#11 library info
        -s display slot(s) info (-c slotID is optional)
        -t display token(s) info (-c slotID is optional)
Others must use -c slotID
        -m display mechanism list
        -I initialize token 
        -u initialize user PIN
        -p set the user PIN
        -P set the SO PIN
        -r remove all objects
        -e enumerate objects
        -d dump all object attributes
Copyright(C) 2011-2016
bash-4.3$

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



После успешного ввода PIN-кода, будет получен весь список сертификатов, как из хранилища GnuGPG, так и хранящихся на подключенных токенах/смарт-картах PKCS#11:



Более того, теперь использовать российскую криптографию в S/MIME для подписания и шифрования переписки могут использовать и другие почтовые клиенты (например, Claws, Evolution), которые используют для этого мехамизмы GnuPg/SMIME:





Вот и все – Kleopatra и ее королевская свита добросовестно служат российской криптографии!

Что дальше?

А дальше надеемся, что в ближней перспективе Kleopatra также будет формировать запросы PKCS#10 для ГОСТ Р 34,10-2001/2012:



Которые затем можно будет передавать в Удостоверяющие Центры и в итоге получать сертификаты.

Но это будет другой сказ.