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

Замечу, что СКЗИ «Рутокен ЭЦП 3.0» является личным ключевым носителем пользователя, и обеспечение к нему разделяемого доступа (если вы подразумеваете возможность управления токеном, подключенным к серверу, различными пользователями с различных рабочих мест) может оказаться небезопасным решением. Тем не менее, такое решение может быть разработано с использованием распространяемых компанией библиотек и фреймворков  и внедрено на страх и риск конечного пользователя (если не запрещается регулятором).

Для локального выполнения PKCS#7-подписи на рабочем месте пользователя, к которому подключен токен, все еще можно использовать openssl (tool) согласно этой инструкции: https://dev.rutoken.ru/pages/viewpage.a … 1%81%D0%B8

А как для Рутокена получить такой же результат? или надо все таки что-то компилить на Си?
Спасибо.

P.s. если Рутокен плагин использовать как криптопровайдер для проверки PKCS#7 - есть утилита командной строки, чтобы обратиться к плагину из php? или запустить что-то типа java -jar  crypto.jar verifysign original.file original.file.cms.p7s > result.txt?

Для проверки на сервере подписи, сделанной с использованием российских криптоалгоритмов, вам не нужен Рутокен Плагин. Рутокен Плагин -- это браузерное решение с API для вызова из javascript. Для проверки на сервере вам может подойти openssl (tool) с подключенным rtengine (проприетарная разработка Рутокен) или gost-engine (https://github.com/gost-engine/engine).

Про openssl+rtengine информация здесь:
https://dev.rutoken.ru/pages/viewpage.a … d=89096210
https://dev.rutoken.ru/pages/viewpage.a … 2%D0%B5CMS
https://dev.rutoken.ru/display/PUB/OpenSSL+API

Самый чистый опыт -- обратиться в официальный УЦ и запросить сертификат с алгоритмами GOST R 34.10-2001 + GOST R 34.11-94, как в случае с Jacarta.

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

я уверен, что о существовании процедуры формирования сертификатов для разных физических токенов по разным криптоалгоритмам знает только 2-3 человека в УЦ, из которых 2 технаря и третий директор, все остальные просто на кнопки жмут в стандартных программах.
они от меня в 1000 км, придется просто тянуть сразу 3 криптопровайдера одновременно для работы с разными токенами.

спасибо за помощь.

P.s. если Рутокен плагин использовать как криптопровайдер для проверки PKCS#7 - есть утилита командной строки, чтобы обратиться к плагину из php? или запустить что-то типа java -jar  crypto.jar verifysign original.file original.file.cms.p7s > result.txt?

В подписи, выполненной Рутокен, используется сертификат с российским криптоалгоритмом GOST R 34.10-2012 (256 бит), подпись выполняется алгоритмами GOST R 34.10-2012 + GOST R 34.11-2012.

Попробуйте выпустить на Рутокен сертификат с теми же самыми алгоритмами, что на Jacarta. Скорее всего, это решит вашу проблему.

В тестовом режиме выпустить сертификат можно в сервисе https://ra.rutoken.ru/ (при генерации ключа выбрать "ГОСТ Р 34.10-2001 — выводится из эксплуатации"). Естественно, такая подпись не проверится государственным сервисом (недоверенный корневой сертификат), но, возможно, ошибка будет другая. Возникновение той же ошибки не подтверждает неверности предположения, потому что сертификат УЦ на https://ra.rutoken.ru/ имеет алгоритм GOST R 34.10-2012 (256 бит).

Самый чистый опыт -- обратиться в официальный УЦ и запросить сертификат с алгоритмами GOST R 34.10-2001 + GOST R 34.11-94, как в случае с Jacarta.

роме того, что в Рутокен Плагин не встроена поддержка идентификаторов казахских алгоритмов

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

https://money.kz/rutoken3.zip в архиве файл я случайно вместо подписи вложил лог утилиты подписи при открыии файла подписи Jacarta/

вот оригинальный бинарник подписи https://money.kz/sign_Jacarta.p7s

В представленных вами подписях:
* при подписи Рутокен используется сертификат, в котором указано, что он соответствует ключу подписи российского криптографического алгоритма подписи (1.2.643.7.1.1.1.1 gost2012PublicKey256 (GOST R 34.10-2012 256 bit public key)))
* в подписи https://money.kz/sign_gov_system.p7s используется сертификат, в котором указан ключ, соответствующий казахскому алгоритм подписи (OBJECT IDENTIFIER 1.3.6.1.4.1.6801.1.5.8)

Кроме того, что в Рутокен Плагин не встроена поддержка идентификаторов казахских алгоритмов подписи (а возникают подозрения, что и в самих алгоритмах есть отличия, учитывая, что сериализация публичного ключа в казахском сертификате занимает 640 бит против 528 бит в российском), в вашем текущем примере для Рутокен Плагин вообще не на чем построить логику выбора между российским и казахским вариантами, потому что на ваш Рутокен записан сертификат с российскими криптоалгоритмами. В ветвлении ГОСТ/RSA Рутокен Плагин выбирает алгоритм подписи как раз по алгоритмам, указанным в сертификате подписанта.

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

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

НО. проблема в том, что Рутокен продается и в РК и КР (рутокен купили в https://ubr.kg), что приводит к нас мысли, что если продажа идет в других странах - то Рутокен Плагин ДОЛЖЕН поддерживать что-то местное из коробки без танцев с бубнами.

т.е. если название/идентификатор алгоритма взять из сертификата ключа, а не из справочника Плугина - то все должно прокатить

в том то и дело, что подпись на Jacarta сфромирована стандартной библиотекой Jacarta, которая висит на их стандартном порту https://localhost:24738/JCWebClient.js

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

поэтому вопрос: вы можете помочь с этим?

Для вас это займет 10 минут, чтобы добавить в справочник дополнительный идентификатор хэша и вставлять его , если в сертификате используется такой идентификатор
или
15 минут, чтобы в команду опций
var sign_options = {detached:true, addUserCertificate:true, addSignTime:true};

добавить параметр типа replaceUserHashOID: '1.1.1.1.1.1.1.1,........' и заменять OID ваш на OID, указанный пользователем, и выкатить свежую версию plugin.js

первый вариант красивее, второй более кастомизированный.

если в Jacarta это работает из коробки - то они просто на эти грабли уже наступали или сделали у себя универсальный алгоритм с использованием нужного OID

я бы не писал так много, но ваша продукция продается активно в КР и надо что-то делать

тогда эксперимент по другому:
https://money.kz/sign_gov_system.p7s - это подпись, которая формируется в облачным госприложением.
предположу, что ее структура аналогична структуре jacarta

Да, структура аналогичная и совпадает с sign_with_Addtime_param.p7s и sign_with_all_param.p7s. Различаются идентификаторы алгоритмов хеширования и подписи:
* Рутокен: 1.2.643.7.1.1.2.2 gost2012Digest256 (GOST R 34.11-2012 256 bit digest) и 1.2.643.7.1.1.1.1 gost2012PublicKey256 (GOST R 34.10-2012 256 bit public key)
* Облачное госприложение: 1.3.6.1.4.1.6801.1.2.1 и 1.3.6.1.4.1.6801.1.2.2 (идентификаторы Казахстана -- https://www.alvestrand.no/objectid/1.3. … 6801.html)

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

Все-таки интересно, каково содержимое подписи при помощи jacarta. Какое ПО используется для подписи в случае использования jacarta? Возможно, оно адаптировано под применение вне РФ.

не содержит der-представления подписи,

тогда эксперимент по другому:
https://money.kz/sign_gov_system.p7s - это подпись, которая формируется в облачным госприложением.
предположу, что ее структура аналогична структуре jacarta

в архиве:
sign_NoTime_param.p7s
параметры создания var sign_options = {detached:true, addUserCertificate:true, addSignTime:false};

sign_with_Addtime_param.p7s
параметры создания var sign_options = {detached:true, addUserCertificate:true, addSignTime:true};

sign_with_all_param.p7s
параметры создания var sign_options = {detached:true, addUserCertificate:true, addSignTime:true, addEssCert: true }

все три варианта приводят к ошибке PKCS#7 signature not valid: 1.2.643.7.1.1.2.2 MessageDigest not available

sign_Jacarta.p7s - создано вебплугином джакарты, ошибки при открытии p7s не вызывает.

все подписи сделаны на один и тот же хэш данных
b8:1d:e5:d8:0c:e6:2f:92:a0:5b:60:e5:cd:3a:59:7d:20:6d:da:da:2c:6e:c6:ee:e1:ed:e1:0d:2b:f4:ea:b3

Можете, предоставить нам:

1) CMS, принимаемую сервером
2) CMS, созданную плагином
3) Также же ошибка возвращается сервером после включения подписанных атрибутов (addSignTime:true, addEssCert: true)?

var sign_options = {detached:true, addUserCertificate:true, addSignTime:true};

включение всех опций:
var sign_options = {detached:true, addUserCertificate:true, addSignTime:true, addEssCert: true };

ничего тоже не дало.