Ошибка эцп cannot create signer gost3411 2012 256withecgost3410 2012 256 signature not available

Обновлено: 25.01.2025

И вот, выполнив свой гражданский долг, я решил еще раз проверить работу электронной подписи в офисном пакете libreoffice.

Для доступа к порталу Госуслуг я использую ОС Linux и браузер Redfox, который представляет собой доработанный с учетом поддержки российской криптографии браузер Mozilla Firefox. Почему я решил это сделать? Как известно, офисный пакет libreoffice в качестве хранилища сертификатов также использует хранилище NSS.

Браузер Redfox-52 был установлен в папку /usr/lical/lib64/firefox-52.

Для подключения библиотек пакета NSS (Network Security Services) с поддержкой ГОСТ-алгоритмов устанавливаем значение переменной LD_LIBRARY_PATH следующим образом:

В качестве хранилища сертификатов в libreoffice как правило используется хранилище сертификатов из браузера Firefox, почтового клиента Thunderbird или интегрированного пакета Seamonkey. Ничто не мешает использовать хранилище сертификатов браузеров GoogleChrome/Cromium или создать свое независмое хранилище (Сервис->Параметры->Безопасность->Сертификат):

После того как выбрано хранилище, подключены библиотеки, запускаем libreoffice, создаем файл формата odt и пытаемся его подписать (Файл->Цифровые подписи->Цифровые подписи).

Сертификаты в хранилище Firefox/NSS успешно отображаются и проверяются:

Однако, подпись после выбора сертификата и нажатия кнопки «ОК» не формируется:

Похоже libreoffice не хочет понимать российские криптоалгоритмы, несмотря на то, что используется NSS из браузера Redfox, который понимает ГОСТ-овые алгоритмы, что подтверждается успешной проверкой сертификатов.

Для этого подготовленный документ экспортируем в PDF-формат. Делаем вторую попытку: на этот раз попытаемся подписать PDF-файл. После его загрузки пытаемся его подписать (Файл->Цифровые подписи->Цифровые подписи) (см.выше, выбираем сертификат, прописываем, например, цель подписания документа): Для подписания PDF-файла его, естественно, необходимо загрузить (Файл->Цифровые подписи->Подписать PDF).

Мы видим, что подпись, сформирования на базе сертификата «Test 12 512» с ключом ГОСТ Р 34. И подпись формируется. Подпись верна. 10-2012 512 бит.

Снова запускаем libreoffice, загружаем подписанный pdf-файл, проверяем подписи. Выходим из libreoffice. Просматривает сертификаты подписантов. Все ОК. Чудеса! Все ОК. Ставим вторую, третью подпись… Все работает. Подпись PDF-файлов работает. Делаем дополнительную проверку. Но что-то не дает покоя.

Находим электронную подпись (/Type/Sig/ ): Открываем подписанный PDF-файл (я использовал встроенный редактор от mc – Midnight Commander — консольный файловый менеджер для Linux).

Копируем ее и сохраняем в файле. Как видим, подпись хранится в символьном шестнадцатеричном виде. Для конвертации файла в бинарный вид (DER-кодировка) воспользуемся утилитой xxd:

$xxd –p –r <файл с подписью из PDF> > <файл>.der $

И тут стало понятно, что не все так хорошо. Да, алгоритм подписи Digest Encryption Algorithm: GOST R 34.10-2012 Key 512 в соответствии с выбранным для подписи сертификатом, но подпись формируется от хэша, посчитанному по алгоритму SHA-256 (Digest Algorithm (1): SHA-256). А это неправильно с точки: хэш для GOST R 34.10-2012 Key 512 должен считаться по алгоритму ГОСТ Р 34.11-2012-512.

В данной статье мы рассматриваем использование пакета NSS для формирования электронной подписи. Приступаем а анализу исходного кода libreoffice: не так страшен черт как его малюют. Если кто предпочитает на платформе MS Windows, использовать CryptoAPI (и, соответственно, ГОСТ-CSP), может по аналогии с данным материалом сделать соответствующую доработку.

3. Анилиз показал, что правки придется внести всего в два файла:
—

/libreoffice-5. 7. 7. 3. 2/xmlsecurity/source/pdfio/pdfdocument.cxx

Выбор хэш-функции будем определять в зависимости от типа ключа сертификата. Эти изменения связаны с правильным выбором хэш-функции для ГОСТ-овых сертификатов. Выбор хэш-алгоритма, например, в PDFWriter::Sign (файл pdfwriter_impl.cxx) будет выглядеть так:

Остальные изменения по логике аналогичны этим. Патч для файла

здесь:

После внесения изменений проводим сборку пакета libreoffice. Внесенные изменения коснулись трех библиотек (/usr/lib64/libreoffice/program):

Именно эти три библиотеки были заменены в установленном дистрибутиве libreoffice (/usr/lib64/libreoffice/program).

И тут на одном из сайтов попадается на глаза такая выдержка:
После этого подписание и проверка ГОСТ-подписи в PDF-файлах прошла без сучка и задоринки.

Заказываем, получаем и проверяем:

Но это естественно. Стоит напомнить, что не следует забывать устанавливать в хранилище цепочку доверенных сертификатов для сертификата подписанта.

Это очень удобно как при согласовании документов, так и хранении документов. Все, теперь есть возможность использования электронной подписи (одной или несколько) в PDF-файлах.

Фактически это была отдельная разработка и это требует отдельной статьи. Разработка велась на Python3 и если на платформе Linux проблем не было, то на MS Windows пришлось попотеть с кодировками. Все эти нюансы можно увидеть в исходном коде.

С помощью этой утилиты можно создать хранилище сертификатов для libreoffice, управлять сертификатами, подписывать файлы и т.д.:

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

И вот если производители отечественных форков Linux доработали различные пакеты (NSS, Firefox, Thunderbiird, GnuPG/SMIME, SSH, KMail, Kleopatra, LibreOffice, OpenSSL, и т.д и т.п.) для работы с российской криптографией, то тогда можно было бы говорить об импортозамещении в области криптографии.

В Windows 10, 2012R2, 2016 не работают примеры для шифрования/расшифрования данных с передачей сессионного ключа. Например, EncryptDecryptSessionKeyTest .
При попытке расшифровать сессионный ключ функция CryptoApi.CryptImportKey выдает ошибку "Плохой ключ" (для VipNet) или "Плохие данные" (для КриптоПро).
Stacktrace:

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

The text was updated successfully, but these errors were encountered:

busyscout commented May 29, 2018

После более детального разбирательства в проблеме выяснилось, что она проявляется при установке алгоритма экспорта сессионного ключа в CALG_PRO_EXPORT и использовании VipNet CSP 4.2.10 в Windows 10, Windows Server 2016. Похоже, что у этого CSP есть какие-то проблемы именно с этим алгоритмом. С этим алгоритмом не работает ни один из примеров шифрования напрямую через CryptoApi, которые указаны в их примерах. Всюду происходит одна и та же ошибка функции CryptImportKey при расшифровке сессионного ключа.

AlexMAS commented May 29, 2018

Я правильно понял, что с CryptoPro CSP такой проблемы нет?

busyscout commented May 29, 2018

Да. С CryptoPro такой проблемы нет. Таким образом, проблема, вероятнее всего, именно в криптопровайдере VipNet последних версий.

AlexMAS commented May 30, 2018

Судя по всему, у VipNet проблемы с Windows 10 тянутся довольно давно. Какие-то вопросы, в том числе с CALG_PRO_EXPORT, остаются открытыми до сих пор. Возможно, я ошибаюсь, поскольку давно заметил, что представители VipNet (Infotecs) неохотно отвечают на вопросы, но определенно что-то делают. :) А вы не пробовали пререключать их загадочную настройку "Включить поддержку работы VipNet CSP через MS Crypto API"? Может что-то получится, хотя слабо верится. Честно говоря, я ещё не успел воспроизвести вашу ситуацию локально, срок бесплатной версии VipNet вышел. Постараюсь почистить машину и переустановить криптопровайдер.

busyscout commented Jun 4, 2018

Для установки алгоритма экспорта ключа (например, CALG_PRO_EXPORT) КриптоПро и Инфотекс используют разные константы для функции CryptSetKeyParam . КриптоПро использует KP_ALGID = 7 , а Инфотекс - KP_EXPORTID = 108 .
До определенной версии Инфотекс также поддерживал константу КриптоПро, а затем перестал. В данной библиотеке жестко зашита константа KP_ALGID = 7 , отсюда и все проблемы.

AlexMAS commented Jun 6, 2018

Я добавил быстро-фикс и опубликовал версию 1.1.1-alpha1. Проверьте, пожалуйста, и дайте обратную связь.

busyscout commented Jun 8, 2018

Теперь вообще шифрование не работает. Ошибка происходит в конструкторе Gost3410AsymmetricAlgorithm .
Скорее всего, это вызвано тем, что константа KP_ALGID используется в разных местах и до этого она некорректно использовалась только при экспорте/импорте сессионного ключа. В других местах она использовалась верно.
Мне кажется, что лучше было бы добавить тип криптопровайдера к классу SafeProvHandleImpl и при экспорте/импорте ключа анализировать его - для КриптоПро использовать одну константу, а для Инфотекс - другую. Кроме того, на данный момент типов криптопровайдеров для Инфотекс три - 2 (ГОСТ 2001), 77 и 78 (ГОСТ 2012).

В Вашем SDK они отсутствуют, где их можно взять?

И еще момент, в первом посте этой темы есть ссылка на актуальную инструкцию, которая открывает форму авторизации. Логин и пароль от этого форума там не подходят. Как можно посмотреть актуальную инструкцию?

Николай Киблицкий
Техническая поддержка
Неактивен

Здравствуйте.
Для интеграции ГОСТ 2012 с Рутокен ЭЦП и OpenSSL нужно пользоваться инструкцией по ссылке.

И еще момент, в первом посте этой темы есть ссылка на актуальную инструкцию, которая открывает форму авторизации.

Данная инструкция устарела.

Здравствуйте.
Для интеграции ГОСТ 2012 с Рутокен ЭЦП и OpenSSL нужно пользоваться инструкцией по ссылке.

И еще момент, в первом посте этой темы есть ссылка на актуальную инструкцию, которая открывает форму авторизации.

Данная инструкция устарела.

Установил драйвера Рутокен, установил OpenSSL. По указанной Вами инструкции скопировал из SDK библиотеки в папку с openssl и добавил путь к ним в файл конфигурации вместе с остальными параметрами:

[gost_section]
dynamic_path = c:\OpenSSL-Win64\bin\rtengine.dll
MODULE_PATH = c:\OpenSSL-Win64\bin\rtpkcs11ecp.dll

При попытке сформировать ключевую пару ГОСТ в файл командой:
openssl genpkey -algorithm gost2012_256 -pkeyopt paramset:A -out seckey.pem

возникает ошибка: Algoritm gost2012_256 not found. В чем может быть причина ошибки?

Vladimir Ivanov
Администратор
Неактивен

возникает ошибка: Algoritm gost2012_256 not found. В чем может быть причина ошибки?

Какая у вас модель токена?

Николай Киблицкий
Техническая поддержка
Неактивен

В пути до библиотек нужно использовать прямой слеш, например:
dynamic_path = C:/OpenSSL-Win64/rtengine.dll

В пути до библиотек нужно использовать прямой слеш, например:
dynamic_path = C:/OpenSSL-Win64/rtengine.dll
MODULE_PATH = C:/OpenSSL-Win64/rtpkcs11ecp.dll

Заменил обратный слеш на прямой и получилось создать закрытый ключ.

В пути до библиотек нужно использовать прямой слеш, например:
dynamic_path = C:/OpenSSL-Win64/rtengine.dll
MODULE_PATH = C:/OpenSSL-Win64/rtpkcs11ecp.dll

Заменил обратный слеш на прямой и получилось создать закрытый ключ.

Теперь у меня проблема с подписанием документов утилитой openssl. Есть Рутокен ЭЦП 2.0 (2000), на нем находится личный сертификат и две неэкспртируемые ключевые пары. Сертификат валидный, цепочка для него тоже. Пытаюсь подписать документ cms подписью:
openssl cms -sign -binary -nosmimecap -in data_to_sign.txt -out signed_cms.txt -outform PEM -keyform engine -inkey "pkcs11:model=Rutoken%20ECP;id=191212102357-007706196340" -engine rtengine -signer Rosteh.cer

Так как необходимо указать сертификат (без ключа -signer у меня возникает ошибка), я экспортировал с рутокена личный сертификат в файл -signer Rosteh.cer

При выполнении команды возникает ошибка:
engine "rtengine" set.
unable to load certificate
2996:error:0906D06C:PEM routines:PEM_read_bio:no start line:crypto\pem\pem_lib.c:686:Expecting: TRUSTED CERTIFICATE

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

openssl dgst -keyform engine -sign "pkcs11:model=Rutoken%20ECP;id=191212102357-007706196340" -engine rtengine -out signature data_to_sign.txt

Вообще мне нужно получить документ подписанный неоткрепленной подписью по ГОСТ 2012.

Содержимое рутокена:

Версия утилиты

Очень надеюсь на вашу помощь в этом вопросе, так как перерыл интернет, но не смог найти решение этой проблемы.

1 января 2019 года вместо ГОСТ Р 34.10-2001 вводится в действие новый стандарт формирования квалифицированной электронной подписи — ГОСТ Р 34.10-2012 (на основании выписки из документа ФСБ России № 149/7/1/3-58 от 31.01.2014 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования»).

Что нового?

С 1 января 2019 все сертификаты ЭП будут выдаваться только по ГОСТ Р 34.10-2012.

Работоспособность сертификатов, выпущенных по ГОСТ Р 34.10-2001 будет действительна до 31 декабря 2019 года. С 01 января 2020 года срок действия этих сертификатов заканчивается.

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

Что сделать для перехода к использованию сертификатов на новом ГОСТ?

Получить новый сертификат, поддерживающий ГОСТ Р 34.10-2012, или дождаться планового обновления сертификата.
Проверить, что установленная версия программы ЭП и шифрования поддерживает работу с сертификатами ГОСТ Р 34.10-2012 (это можно уточнить у фирмы-разработчика используемой программы). Если версия не поддерживает новый алгоритм, ее необходимо обновить.
Обновить настройки в 1С:Документообороте.

Что настроить в 1С:Документообороте?

Для работы с сертификатами по новому алгоритму ГОСТ Р 34.10-2012 в 1С:Документообороте нужно изменить следующие настройки:

Шаг 1. Открыть настройки ЭП и шифрования (Настройка и администрирование — Настройка программы — Общие настройки)

Шаг 2. В настройках на закладке «Программы» добавить новую или изменить существующую настройку программы ЭП и шифрования.

Читайте также: