Технологии безопасности

Сайт посвященный вопросам безопасности

Сказание о Клеопатре и о российской криптографии (Продолжение)

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


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

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