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

    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

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

    Но это будет другой сказ.
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 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.

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