2 декабря 2016 в 16:58

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

imageС появлением библиотеки GCrypt-1.7.0 с поддержкой российской криптографии (ГОСТ 28147-89, ГОСТ Р 34.11-94/2012 и ГОСТ Р 34.10-2001/2012), стало возможным говорить о поддержке российского PKI в таких проектах как Kleopatra и KMail.

imageKMail – это почтовый клиент, который для обеспечения безопасности переписки позволяет подписывать и шифровать сообщения по протоколу S/MIME. И то и другое базируется на архитектуре PKI, сертификатах X509 и протоколах CMS/PKCS#7:

image

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

image

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

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

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

image

В поле «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 встала на сторону российской криптографии.

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

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

imageДля импорта личного сертификата в среду Клеопатры (правильнее сказать в хранилище сертификатов и закрытых ключей в 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, который мы и будем импортировать:

image

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

image

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

image

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

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

image

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

image

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

image

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

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

image

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

image

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

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

image

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

image

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

image

imageНо хочется большего. Речь идет об использовании программно-аппаратных токенов 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-код для доступа к токену:

image

Проверить имя токена, можно воспользовавшись свободно распространяемой утилитой 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$

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

image

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

image

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

image

image

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

Что дальше?

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

image

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

Но это будет другой сказ.
Орлов Владимир Николаевич @saipr
карма
16,0
рейтинг 0,0
Программист

Самое читаемое Разработка

Комментарии (16)

  • +2
    Спасибо за статью!
    • 0
      И вам огромное спасибо за понимание!!!
  • +1

    В PKCS#12 имени ТК26 изменен алгоритм формирования ключа для подписи. Вместо специального алгоритма из PKCS#12 используются последние 32 байта из 96-байтного вывода PBKDF2. Hope this helps.


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

    • 0
      Да все именно так. Это учтено и реализовано в LCC2012, LS112016 и LCSSL.
      • +1

        Интересно, получил PKCS#12 с Вашего тестового УЦ, тестирую со своим кодом. Не сходится MAC, хотя в примерах ТК26 проверка PKCS#12 MAC проходит успешно.

        • +1
          В данном случае происходит следующее. Вы проверяете полученный P12 по новым требованиям ТК-26. Тестовый сервер выдает P12 ориентируясь на прежние требования. Это связано с тем, что большинство используют openssl с ГОСТ-ым engine-ом для работы с P12. Мы в своих приложениях для совместимости с прежними реализациями PKCS#12 делаем две проверки MAC: и по-старому и по-новому. Если хоть одна из них сошлась — значит все хорошо.
          В утилите openssl можно, кстати, отключать проверку MAC.
          Вы тоже можете у себя использовать обе проверки.
          • +1

            Да, сошлось. Спасибо.

            • 0
              Не за что. Вам спасибо.
              Приятно когда говоришь с человеком на одном языке!
  • +1

    Еще, у Вас в server_csr не проходит создание ключей -2012, только -2001:


    Error 7711011

    General Error Cannot create keypair!
    7711011
    • 0
      Да, это так. Т.е. сам тестовый УЦ сегодня генерить только keypair-2001. Но если отправить P10 с публичным ключом по ГОСТ Р 34.10-2012, то сертификат получите.
      Спасибо за подсказку (сам, к сожалению) не проверил. Как только поправят — я сообщу.
      Еще раз спасибо.
    • +2
      С ошибкой «Cannot create keypair!» для ключей -2012 разобрался. В понедельник поправим.
    • 0
      Все исправлено. Проверил. Могу выслать P12.
      Можете проверить создание ключей-2012!!!
      Еще раз — Спасибо!
  • 0
    Лет этак 7 назад переходили в компании с PGP на Клеопатру + GnuPG.

    И вот вроде работает оно по сути так-же, как платный PGP, но интерфейс и его логика написаны явно не людьми и не для людей. Столько хороших и добрых слов тогда пришлось выслушать от пользователей…
    • 0
      А что вам не нравится в вашей реализации? И интерфейс кого не нравится? Kleopatra? Вы используете GnuPgp или S/MIME? Здесь речь идет обиспользовании S/MIME!!! И это как говорится, большая разница.
  • 0
    стоит добавить обзац есть ли backdoor в этих шифрах
    • 0
      В каких «этих шифрах»? В ГОСТ-ах? Этот вопрос надо задать разработчикам LibGCrypt! Ведь именно эта библиотека используется как шифрсредство. И этому, наверное, должен быть посвящен не один абзац, а целое исследование библиотеки LibGCrypt.

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