Linux openssl gost 2012

Linux openssl gost 2012

Docker image with OpenSSL 1.1.1, GOST engine and cURL

This image was built to have ability to connect to servers with GOST SSL certificates. In addition, it helps to encrypt, decrypt, hash messages with GOST algorithms.

Since version 1.1.1 OpenSSL does not contain GOST-engine anymore, but it can be compiled and used separately. This image does this work.

Output of openssl ciphers supports:

There are some issues with OpenSSL 1.1.1 and GOST-engine (GOST ciphers are not in list), so versions are fixed in default docker’s build args.

You can pull my docker container: docker pull gosha20777/openssl-gost:dev . if you want to build a docker image yourself or build it into your host mashine, see the instructions below.

Build form sh script

The image has been built and pushed into https://hub.docker.com/repository/docker/gosha20777/openssl-gost. In examples below I use image rnix/openssl-gost from Docker Hub, but you can build this image for you own and use your tag.

As usual, you can run commands directly from host or you can use ‘interactive mode’ with -i . Pull the image and run a container with mounted current dir in interactive mode:

Run command with mounted current dir without interactive mode:

If you use Windows, pwd is incorrect. Use absolute path instead, for example:

In the container you run commands.

To show certificate of host with GOST

To send a file to host with POST and save the response into new file

To generate new key and certificate with Signature Algorithm: GOST R 34.11-94 with GOST R 34.10-2001

To sign file with electronic signature by GOST using public certificate (-signer cert.pem), private key (-inkey key.pem), with opaque signing (-nodetach), DER as output format without including certificate and attributes (-nocerts -noattr):

To extract data (verify) from signed file (DER-format) using public certificate (-certfile cert.pem) issued by CA (-CAfile cert.pem) (the same because cert.pem is self-signed):

Certification authority (CA)

In Russia, it is common to issue GOST-certificates signed by CA which are not worldwide trusted. In this case you get error. For example, curl: (60) SSL certificate problem: unable to get local issuer certificate . To solve this problem you have two options: 1) do not verify CA (not recommended), 2) find and use CA.

To ignore security error use -k with curl and -noverify with openssl. For example curl https://gost.examples.com -k or openssl cms -verify -noverify .

Find and download CA-certificate file. For example, CryptoPRO CA. It is PKCS7, but you need PEM. Run command to extract all certificates from p7b and write them as a chain of certificates in one file:

When you have CA-file you can:

• Install it in default CA certificate store
• Specify it in every openssl or curl command

To install it in default CA certificate store use commands:

To specify it in curl:

To specify it in openssl with verifying signature:

Usage in other Dockerfiles

Compiled libraries can be used in other Dockerfiles with multi-stage approach. Basic template is in any-gost directory. Working example with PHP is in php-fpm-gost directory.

There some notices:

• OpenSSL and cURL are build in custom directory /usr/local/ssl and usr/local/curl which contain bin , include , lib .
• Before compiling the main Dockerfile folders /usr/local/ssl and usr/local/curl should be copied into new image.
• During building packages openssl and curl can be installed and overwrite new /usr/bin/openssl and /usr/bin/curl .
• Specify paths of libraries in configuring scripts to new locations.

Источник

ЭЦП по ГОСТ на GNU/Linux с помощью OpenSSL

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

Удостоверяющий Центр выдал нам ключ и сертификат в одном PKCS#12 файле auth.p12
Я исхожу из того, что у нас в наличии есть linux и docker. Можно даже не локально — вполне можно закинуть наш документ куда-нибудь на хостинг и подключиться по SSH. Подробности установки docker и работы с докер-образами оставим за пределами этой заметки. Перейдём сразу к делу:

Прямо из папки, где лежит наш документ на подпись (document.pdf) и PKCS#12 файл (auth.p12) запускаем замечательный docker образ OpenSSL с поддержкой ГОСТ и заходим в контейнер:

sudo docker run —rm -i -t -v `pwd`:`pwd` -w `pwd` rnix/openssl-gost bash

Вытаскиваем из PKCS#12 файла приватный ключ и сохраняем его в pem-формате. Может потребоваться ввести ваш пароль от PKCS#12 файла.

openssl pkcs12 -in auth.p12 -out key.pem -engine gost -nodes -clcerts

Аналогично вытаскиваем из PKCS#12 файла и сертификат.

openssl pkcs12 -in auth.p12 -clcerts -nokeys -out pub.crt

Подписываем документ. Подпись будет отсоединенная, в формате PKCS#7 в отдельном файле (document.pdf.sig)

openssl smime -sign -signer pub.crt -inkey key.pem -engine gost -binary -noattr -outform DER -in document.pdf -out document.pdf.sig

Проверить подпись можно много где, как локально так и на сайте госуслуг, например.
Всё. Можно отправлять контрагенту документ и соответствующий sig файл.

Если вдруг у вас сертификат в формате DER (в Windows часто это файл с расширением .cer), то можно конвертировать такой сертификат в pem-формат:

Источник

Об open-source реализациях хэш-функции ГОСТ Р 34.11-2012 и их влиянии на электронную подпись ГОСТ Р 34.10-2012

В свое время реализация отечественных криптографических алгоритмов в библиотеке libgcrypt очень меня вдохновила. Стало возможным задействовать эти алгоритмы и в Kleopatra и в Kmail и в GnuPg в целом, рассматривать библиотеку libgcrypt как алтернативу openssl с ГОСТ-ым engine. И все было замечательно до прошлой пятницы.

Меня попросили проверить электронную подпись ГОСТ Р 34.10-2012-256 для документа, созданного в Microsoft Office на MS Windows. И я ее решил проверить в Kleopatra (у меня стоит Linux). И что вы думаете, подпись оказалась неверной. Закрались сомнения. Решил проверить на openssl с ГОСТ-овым engine. Подпись успешно была проверена. Срочно переподписал файл в Kleopatra и он не прошел проверку на MS Windows. Попробовали другие файлы подписать и проверить, все было нормально. Встал вопрос в чем беда? Поскольку при подписании участвует хэш документа, было решено проверить вычисление хэш разными программами. Прежде всего были задействованы open-source реализации для stribog:

• Знаменитая реализация Дегтярева
• Реализация в libgcrypt
• LibreSSL
• OpenSSL engine

И тут случился шок! Хэш, подсчитанный «знаменитой реализацией Дегтярева» совпадал с хэшом, посчитанным в openssl с ГОСТ-ым endine, но не совпадал со значением хэш, посчитанным с помощью libgcrypt и libressl.

Как был прав ru_crypt, когда в начале своей статьи написал:

Сразу предупреждаю, что корректность реализаций не проверял.

Кстати, в самом стандарте на ГОСТ Р 34.10-2012 тоже написано, что контрольные примеры носят справочный характер. Надо четко понимать, что контрольные примеры не гарантирует, что разные реализации дают один и тот же результат на все случаи жизни.

Для вычисления хэш-значений использовались утилиты следующего вида:

4) Знаменитая реализация Дегтярева

Вот тоже интересная вещь: в латинской транскрипции стрибог пишут то stribog, то streebog. Неплохо бы прийти к единообразию. А так кажется, что это разные функции. Лично мне предпочтительней первый вариант – stribog.

Нужен был третейский судья, чтобы решить кто вычисляет хэш верно.

В качестве третейского судьи было решено использовать токен PKCS#11 РУТОКЕН ЭЦП-2.0, который поддерживает российские криптографические стандарты ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, VKO ГОСТ Р 34.10-2012 (RFC 7836) с длиной ключа 256 и 512 бит, и сертифицирован ФСБ России как средство криптографической защиты информации (СКЗИ) и средство электронной подписи.

К тому же токен РУТОКЕН ЭЦП-2.0 широко распространен и многие на нем хранят сертификаты для доступа на Госуслуги и другие порталы.
Для вычисления значения хэша на токене воспользуемся скриптом test_digest.tcl на языке Tcl:

Когда проявляется это расхождение в реализации? Пока что удалось определить, что данное расхождение возникает при подсчете хэш doc-файлов, созданных в MS Office. Причем хэш от первых 143 байтов считается одинаково, а уже при подсчете хэш от 144 байтов значения получаются разные.

Первые 143 байта в шестнадцатиричном виде выглядят так:

Сохраним их в файле Doc1_143_hex.txt.

Первые 144 байта в шестнадцатиричном виде выглядят так:

Сохраним их в файле Doc1_144_hex.txt.

Для перевода из шестнадцатеричного вида в бинарный удобно воспользоваться скриптом hex2bin.tcl:

Преобразуем шестнадцатеричный код в бинарный:

Теперь можно проверить как вычисляется хэш различными реализациями:
Сначала посчитаем хэш для файла Doc1_143,bin:

Наступил самый важный момент, момент проверки на сертифицированном СКЗИ:

Как видим, все завершилось для файла Doc1_143.bin хорошо, все хэши совпали.

Посмотрим, что будет для файла Doc1_144.bin:

Всё, значения хэшей не совпадают. Для чистоты эксперимента проверим и оставшиеся реализации:

Хэш, подсчитанный «знаменитой реализацией Дегтярева» совпадает с хэшом, подсчитанным в openssl с ГОСТ-овым engine, но не совпадает со значением хэша, посчитанным с помощью libgcrypt и libressl.

Аналогичный результат мы получим, если будем считать хэш stribog512.

Вывод один. Если вы хотите, чтобы электронная подпись ГОСТ Р 34.10-2012, формируемая средствами libressl и libgcrypt (а может и другими), была совместима с реализацией в openssl и, самое главное, с реализацией в СКЗИ, сертифицированных в системе сертификации ФСБ России, используйте проверенные реализации для вычисления хэшей. Надеюсь, эта публикация позволит избежать многих недоразумений, а авторам реализации stribog в libressl, libgrypt и возможно других поможет устранить эти расхождения. Сегодня, надо признать, в вышеназванных продуктах фактически реализован не ГОСТ Р 34.10-2012, а что-то другое. Это другой алгоритм. Приведенный тестовый пример, наверное, неплохо было бы включить как тестовый пример для ГОСТ Р 34.10-2012. А я иду править libgcrypt для Kleopatra и KMail. Сказание о Клеопарте и российской криптографии оказалось неоконченным.

Источник

Как настроить Linux для входа в домен с использованием алгоритмов ГОСТ

Введение

Протокол Kerberos 5 сейчас активно используется для аутентификации. Особенностью данного протокола является то, что он осуществляет аутентификацию, базируясь на четырех китах:

1. Симметричное шифрование;
2. Хеширование;
3. ЭЦП;
4. Третья доверенная сторона.

Начиная с пятой версии появилась возможность использовать еще асимметричное шифрование (для электронной подписи). Более подробно на работе протокола Kerberos останавливаться не имеет смысла, ибо описание алгоритма можно посмотреть тут.

К сожалению, количество алгоритмов шифрования, хеширования и ЭЦП, которые использует данный протокол, не настолько велико, насколько хотелось бы, поэтому в данной статье я хочу показать, как добавить легко и просто собственные алгоритмы в реализацию данного протокола MIT’ом. Добавлять же мы будем наши отечественные алгоритмы: ГОСТ 28147-89 (aka Магма), ГОСТ Р 34.11-2012 (aka Стрибог) и ГОСТ Р 34.10-2012 (хотелось бы тоже иметь для него aka, но я не знаю:(). Готовое решение для данных алгоритмов можно его найти в моем репозитории. На стороне клиента мы будем использовать аппаратные реализации алгоритмов ГОСТ в Рутокене ЭЦП 2.0 и их программные реализации в engine GOST для openssl. Но самый безопасный вариант хранения ключей – когда они генерируются непосредственно на Рутокене и никогда не покидают его память во время криптографических операций. Для такого варианта работы потребуется rtengine.

Перед тем, как приступить к внедрению алгоритмов, опишем основные места, где будут производится изменения. Внутри директории src/lib/crypto/ находятся реализации всех алгоритмов, отвечающих за симметричную криптографию и хеширование. В ней имеются 2 реализации этих криптографических алгоритмов: встроенная(builtin) и openssl. Дабы сэкономить время и место, мы, естественно, будем добавлять реализации алгоритмов с помощью openssl, в котором они уже есть (ну или почти есть, но об этом чуть позже). Для добавления же асимметричных алгоритмов, нужно будет подправить плагин src/plugins/preauth/pkinit

Если у вас еще не настроен Kerberos, то инструкцию по его первичной настройки и эксплуатации можно взять тут. В дальнейшем автор полагает, что вы работаете с доменом AKTIV-TEST.RU

Добавление алгоритмов хеширования и симметричного шифрования

Как уже было ранее озвучено, мы не будем писать алгоритмы шифрования и хеширования с нуля, а воспользуемся готовой реализацией данных алгоритмов в openssl. Напрямую openssl не поддерживает в себе реализацию отечественных алгоритмов, но обладает мобильностью в данном вопросе и позволяет добавлять новые алгоритмы, используя механизм engine GOST для работы с ключами в файловой системе и, хранящие на токене — rtengine.

Небольшое введение в механизм engine openssl и подключение engine GOST

Engine в openssl – это небольшая динамическая библиотека, которую openssl подгружает в runtime по требованию. Каждая такая библиотека, должна содержать в себе определенные символы (функции) для загрузки необходимых алгоритмов. В данной работе мы воспользуемся engine gost, который содержит в себе все необходимые отечественные криптографические алгоритмы.

Установка дичайше проста, например, и происходит следующим образом:

Выкачиваете из репозитория реализацию данного энджина.

собираете библиотеку с ним (mkdir build && cd build && cmake… && make):

В директории bin (КОТОРАЯ ПОЯВИТСЯ В КОРНЕВОМ КАТАЛОГЕ ПРОЕКТА. ) будет лежать динамическая библиотека gost.so – это и есть наш энджин. Его нужно будет перенести в директорию, где хранятся энджины openssl. Узнать месторасположение данной директории можно с помощью:

Дело за последним – нужно сказать openssl, где находится данный энджин и как он называется. Сделать можно это с помощью изменения файла конфигурации openssl.cnf. Месторасположение которого можно узнать с помощью:

В конец данного файла нужно будет внести следующее содержимое:

После этого данный энджин должен появится в openssl. Проверить его работоспособность можно заставив, например, сгенерировать приватный ключ в файле по ГОСТ Р 34.10-2012:

Флаг -engine как раз говорит о том, какой engine нужно подгрузить перед началом работы для того, чтобы стал виден алгоритм генерации ключей для ГОСТ Р 34.10-2012.

Реализация алгоритма хеширования

Начнем с самого простого – с реализации алгоритма Стрибог. Kerberos обладает жесткой связью алгоритма хеширования и шифрования, то есть вы не можете просто так взять и выбрать для шифрования один алгоритм, а для хеширования другой – вам нужно будет встроить связку алгоритма хеширования и шифрования. Причина этого мне не известна, но раз там бытуют такие правила – давайте попробуем создать связку алгоритма Стрибог и AES.

Т.к. нам понадобится уверенность в подключении в разных местах нашей программы, давайте создадим сначала небольшую библиотеку gost_helper, которая будет содержать в себе функцию инициализации энджина в openssl, а так же для удобства несколько функций, возвращающих контексты некоторых алгоритмов хеширования – нам это поможет в дальнейшем. Назовем эту библиотеку gost_helper и создадим для нее соответствующий заголовочник и исходный файл в директории src/lib/crypto/openssl/:

После добавления вспомогательной библиотеки необходимо будет объявить о ее существовании в Makefile и выписать ее зависимости от файлов. Для этого добавим следующее:

Стоит заметить, что в дальнейшем при подключении данной библиотеки, нам надо будет добавлять зависимости некоторых файлов от заголовочника данной библиотеки. Делается это очень просто – отыскивается цель, куда надо добавить зависимость в deps файле и записывается зависимость от rel/path/to/gost_helper.h. Например, в src/lib/crypto/openssl/hash_provider/deps нужно будет добавить следующее:

В целях экономии места в статье и чтобы размять ваши мозги, я больше не буду обращать на это внимание: будьте внимательны и осторожны!

Добавим теперь реализации функций хеширования, все их реализации у нас лежат в src/lib/crypto/openssl/hash_provider/hash_evp.c. Туда нужно будет дописать следующее:

Теперь надо объявить эти контексты во всей библиотеке. Для этого нужно создать их описание в файле src/lib/crypto/krb/crypto_int.h.

Объявим идентификатор связки Стрибог и AES, внедря макросы, которые мы назовем CKSUMTYPE_STRIBOG_256_AES256, CKSUMTYPE_STRIBOG_512_AES256, ENCTYPE_AES256_CTS_STRIBOG_256, ENCTYPE_AES256_CTS_STRIBOG_512. Их надо объявить в шаблоне заголовочного файла src/include/krb5/krb5.hin. Выглядеть это будет примерно так:

Теперь необходимо добавить две связки функции хеширования и шифрования и функции шифрования и хеширования. Зачем две, если они эквиваленты, спросите вы? Ответ: не знаю, или это исторический костыль или способ оптимизации. Тем не менее, давайте добавим в необходимые файлы новые структуры:

Казалось бы уже все, а вот и нет! Далее наступают проблемы, которые будут видны только в процессе отладки, некоторых из них можно было бы избежать, указав, например, другие указатели на функции в вышеуказанных структурах, но мы пойдем более сложным путем, чтобы показать, что еще возможно придется исправить по дороге. Обо всех этих проблемах я узнал только пользуясь отладчиком:

После всех этих изменений можно проверить работу алгоритма. Соберем все, что мы наделали.

Теперь приступим к проверке. Для этого давайте выставим принудительное использование внедренных нами алгоритмов в файлы конфигурации Kerberos. Выполните следующее:

Подправим файл конфигурации kdc.conf (у меня это /usr/local/var/krb5kdc/kdc.conf). Выставим принудительное хеширование с помощью нововведенного алгоритма:

Аналогичные изменения в файле конфигурации всего протокола krb5.conf (у меня он находится по адресу /etc/krb5.conf):

Далее запустим krb5kdc т.к. изменился master_key, то возможно придется создать базу данных principals заново с помощью krb5_newrealm.

После этого создаем всех необходимых принципалов и можно начать работу. Попробуйте аутентифицироваться с помощью kinit.

Проверим, что хеширование происходит по указанному алгоритму можно с
помощью klist -e.

Если сервис не запускается, то его можно запустить из-под рута с помощью src/kdc/krb5kdc. Если все запустилось, прошло гладко – поздравляю вас! Иначе – увы, панацею от всех проблем я не предлагаю, а лишь предлагаю «небольшую» инструкцию, содержащую основные шаги, которые вам придется совершить, дабы внедрить новый алгоритм в Kerberos. И если у вас ничего не вышло – берите в руки gdb и смотрите, где что выходит не так. Вам лишь могу дать несколько советов:

1. собирать проект в режиме отладки можно, если передать в ./configure CFLAGS=» -g -O0″;
2. запустить krb5kdc не в фоновом режиме можно с помощью флага -n;
3. надеюсь до этого не дойдет (хотя при реализации асимметричных алгоритмов у меня все-таки дошло) – возможно вам потребуются отладочные символы openssl – установите их или взяв из репозитория, или установив openssl из исходников с отладочными символами;
4. то же самое касается gost engine.

По идее этого набора советов вам должно хватить для того чтобы избавить себя от лишней траты времени в поисках «неизведанного».

Реализация алгоритма шифрования

В этом разделе я покажу, как можно добавить свой алгоритм шифрования данных в Kerberos, и мы попробуем создать связку Магмы и Стрибога, добавленного в прошлом разделе. Тут я уже предполагаю, что небольшая библиотека gost_helper уже была добавлена в прошлом разделе. Ну что же, разминаем пальцы и приступаем:

Сначала опишем алгоритм в нашей библиотеке libk5crypto описав их в заголовочном файле src/lib/crypto/krb/crypto_int.h.

В директории src/lib/crypto/openssl/enc_provider добавим исходник gost.c, содержащий в себе реализацию всех необходимых алгоритмов (за основу я взял исходник алгоритма des). Важно заметить, что мы реализуем только режим шифрования cbc, так что для самопроверки вы можете взять любой другой режим шифрования и добавить его:

В шаблоне src/lib/crypto/openssl/enc_provider/Makefile.in укажем, что появился новый исходник:

Не забываем про указание зависимостей в src/lib/crypto/openssl/enc_provider/deps:

Добавим идентификаторы связок к src/include/krb5/krb5.hin:

Опишем структуру связок функции хеширования и шифрования, как в прошлом разделе:

Добавим в список режимов шифрования по умолчанию в файле src/lib/krb5/krb/init_ctx.c:

После этих манипуляций можно попробовать протестировать нововведенный алгоритм. Тестирование происходит аналогичным образом, что и в прошлом разделе. Имя связки можно взять в виде алиаса (например, gost89-stribog512) или с помощью имени самого алгоритма (например, gost89-cbc-stribog-512). Надеюсь, что все заработает, иначе не забывайте о том, что я сказал ранее.

Добавление алгоритма цифровой подписи

Ура! Мы приступаем к финальному разделу данной статьи и попробуем добавить собственный алгоритм электронной подписи. Не стоит пугаться, его добавить проще чем что-либо еще, так что давайте поскорее приступим… Хотя нет, подождите, для начала небольшая ремарка.

Асимметричное шифрование, достаточно, тяжеловесная штука. Одна из его главных особенностей – возможность аутентификации: все это построено на удостоверяющих центрах, сертификатах и всякой-всякой сложной лабуде. Как говорится.

Ребята, не стоит вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не архивы спецслужб. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте, что тут писалось. Я вполне понимаю, что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь пытливых — стоп. Остальные просто не найдут.

Как-то так. Ну что же, если у вас хватило смелости приступить к этому, то давайте начнем. В данной статье я покажу вам два способа получения и хранения приватных ключей и сертификатов: в файловой системе и на токене. В сущности, для обоих применима Аксиома Эскобара, но для второго способа потребуется дополнительный энджин, так что если вы решитесь пойти путем шиноби, то милости просим в данный раздел, остальные могут его пропустить.

Настройка openssl для работы с токенами (на примере Рутокен)

Для работы с Рутокенами, аппаратно поддерживающими ГОСТ-криптографию, для openssl существует rtengine. Его установка достаточно проста и не сильно отличается от GOST, нужно только знать, что и где брать.

Скачиваете отсюда SDK rutoken разработчика и достаете из папки sdk/openssl/rtengine/bin/ собранную под вашу платформу библиотеку с энжином и помещаете в папку с engine.

Скачать и установить модуль librtpkcs11ecp.so. отсюда

Собирать утилиту из ветки master OpenSC взяв коммит 8cf1e6f

После того как мы все это сделали, осталось настроить конфигурационный файл openssl.cnf:

Работоспособность engine мы проверим на деле.

Создание приватного ключа и сертификата для принципала, KDC и УЦ

За основу данной инструкции была взята инструкция по настройке kerberos. Я лишь адаптировал ее для работы с русскими алгоритмами, так что частично заглядывайте туда.

Создадим приватный ключ и сертификат удостоверяющего центра, а также приватный ключ, запрос на сертификат и сам сертификат, подписанный УЦ для KDC:

Изменим конфигурационный файл kdc, чтобы он знал, откуда брать ключи и сертификаты:

[libdefaults]
spake_preauth_groups = edwards25519

Создадим приватный ключ и заявку на сертификат для нашего принципала. Тут будет развилка, и надо выполнить разные действия в зависимости от того, где мы будем хранить приватный ключ: на токене или в ФС:

Для создания ключа и заявки в ФС все делаем почти аналогично, как для KDC:

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

Теперь подпишем нашу заявку:

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

Настраиваем файл конфигурации клиента (у меня это /etc/krb5.conf):

Надеюсь, что на данном этапе проблем не возникнет. Мы совсем близко! Добавим реализацию новых алгоритмов.

Добавление нового алгоритма цифровой подписи

Алгоритмы ЭЦП добавить куда проще чем те, что рассматривались ранее – придется заменить всего-то 2 файли! src/plugins/preauth/pkinit/pkcs11.h и src/plugins/preauth/pkinit/pkinit_crypto_openssl.c

Начнем с добавления идентификаторов новых механизмов и ключей в заголовочник pkcs11.h. Идентификатор механизма – это название алгоритма, который подается токену для того, чтобы он его совершил. Все эти идентификаторы стандартизированы и их можно найти в интернете (хоть и с большим трудом). Наши я нашел здесь в sdk/pkcs11/include/rtpkcs11t.h. Добавим в заголовочник следующие идентификаторы ключей и механизмов:

Всеми ими мы не воспользуемся, но на будущее можно добавить.

В файле pkinit_crypto_openssl.c, в первую очередь, нужно добавить подгрузку энджинов перед началом работы. Вызов этой функции также нужно вставить перед get_key, т.к. эта функция почему-то вызывается перед подгрузкой энджинов:

После инициализации энджинов можно приступить к замене механизмов и электронной подписи. В данный момент жестко зашит только один алгоритм – RSA с хешом, полученным из sha1. Мы же встроим выбор между возможными режимами в зависимости от типа ключа, хранящегося на токене или в ФС. Для этого введем несколько функций, которые будут на вход получать контексты шифрования, а на выходе выдавать необходимые идентификаторы алгоритмов и механизмов. Также будет необходимо немного подправить функцию получения хендла приватного ключа с токена, т.к. она возвращает только RSA ключи:

Теперь лишь осталось в функциях создания цифровой подписи cms_signeddata_create и create_signature заменить жесткую установку алгоритма на выбор алгоритма в зависимости от контекста:

После всех этих манипуляций вы можете попробовать зайти, используя токен или сертификат в файловой системе (во втором случае, вероятно, потребуются права рута):

Если после запроса пароля токена не потребовалось вводить пароль user, значит, все отработало правильно.

Все замечания и вопросы вы можете писать в комментариях, а я постараюсь на них оперативно ответить.

Источник