Crypto API
Добрый день!
Пытаюсь использовать rutoken для подписания, шифрования данных. Получилось подписывать только с использованием MD5RSA (1.2.840.113549.1.1.5), думаю ещё и SHA1 получится. Такой вопрос: а как подписывать с использованием ГОСТ?
Вы не авторизованы. Пожалуйста, войдите или зарегистрируйтесь.
Форум Рутокен → Техническая поддержка разработчиков → Crypto API
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Добрый день!
Пытаюсь использовать rutoken для подписания, шифрования данных. Получилось подписывать только с использованием MD5RSA (1.2.840.113549.1.1.5), думаю ещё и SHA1 получится. Такой вопрос: а как подписывать с использованием ГОСТ?
Здравствуйте, какая модель токена используется?
Rutoken ECP
Версия: 16.00.09.00
Это?
Я использую криптопровайдер Aktiv Rutoken CSP v1.0.
Rutoken ECP
Версия: 16.00.09.00Это?
Я использую криптопровайдер Aktiv Rutoken CSP v1.0.
Да, спасибо.
Криптопровайдер Aktiv Rutoken CSP не поддерживает шифрование и подпись по ГОСТовым алгоритмам, увы.
Функции, связанные с ГОСТовыми алгоритмами, реализованы в библиотеках PKCS#11, соответственно их можно использовать из OpenSSL с поддержкой ГОСТ, из Рутокен плагина (https://www.rutoken.ru/products/all/rutoken-plugin/), а также из различных крипторовайдеров (например Signal-COM CSP, ViPNet CSP).
Опишите пожалуйста задачу, которую нужно решить.
Нужно обеспечить подписание, шифрование ГОСТовыми алгоритмами с использованием Rutoken (возможен вариант через Crypto-PRO), используя CryptoAPI, дело в том что пока удалось подписывать и шифровать только через этот криптопровайдер (Active Rutoken CSP), пробую через Крипто-про, но почему то ошибка все равно возникает что криптопровайдер не поддерживает алгоритм.
Установил КриптоПро Рутокен CSP. В КриптоПро настроил считыватели смарт карт. КриптоПро Рутокен CSP токен видит, но сертификаты на нем не видно через "Просмотреть сертификаты в контейнере...", хотя они там есть (через rtCert их видно.). Есть криптопровайдер Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider и GOST R 34.10-2001 Rutoken CSP. Через КриптоПро когда ключи находятся в реестре подписывается успешно. Вставляю токен, в хранилище "Личное" появляются сертификаты, которые на токене, но при подписании одним из сертификатов (CryptSignMessage) возникает ошибка, соответствующая тому что криптопровайдер не поддерживает алгоритм (при использовании ГОСТ алгоритмов).
Насколько я понимаю КриптоПро Рутокен CSP это как раз прослойка между PKCS11 интерфейсом токена и КриптоПро, но вот что-то не заводится.
Когда генерирую запрос на сертификат, то если использую криптопровайдер "Active Rutoken CSP", то появляется окно с запросом пароля, а если через Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider, то он просит выбрать носитель, но токен выбрать не дает, говорит что устройство недоступно или не отформатировано.
Вроде подробно описал что происходит.
Мне нужно генерировать сертификат с использованием Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider или GOST R 34.10-2001 Rutoken CSP ,или это не принципиально? OST R 34.10-2001 Rutoken CSP - зачем добавился этот криптопровайдер? Непонятно почему криптоПро не может обратиться к токену. КриптоПро 3.6.6497.
Удалил КриптоПро вообще, поставил только КриптоПро Рутокен CSP, остался крипто провайдер GOST R 34.10-2001 Rutoken CSP, при запросе на сертификат ошибка 0x8009001F. Окна для ввода пароля не появляется. В реестре HKLM\microsoft\cryptography\calias\smartcards\ есть ветка CP_Rutoken_FKC в поле CryptoProvider GOST R 34.10-2001 Rutoken CSP. Есть записи Rutoken,RutokenECP с криптопровайдером Active Rutoken CSP.
Нужно обеспечить подписание, шифрование ГОСТовыми алгоритмами с использованием Rutoken (возможен вариант через Crypto-PRO), используя CryptoAPI, дело в том что пока удалось подписывать и шифровать только через этот криптопровайдер (Active Rutoken CSP), пробую через Крипто-про, но почему то ошибка все равно возникает что криптопровайдер не поддерживает алгоритм.
Если есть требование обеспечивать подпись на неизвлекаемом ключе "на борту" токена и использовать для этого именно интерфейс CryptoAPI, придется использовать CSP типа Signal-COM CSP или ViPNet CSP (последний вроде даже бесплатный).
КриптоПро CSP не задействует криптографические возможности токенов, а использует их исключительно в качестве ключевых носителей. В данном случае и не обязательно применять Рутокен ЭЦП, достаточно Рутокен S или Рутокен Lite.
КриптоПро Рутокен CSP - это отдельный криптопровайдер, который задейсвует криптографически возможности Рутокена, используя
спецификацию ФКН. Существует отдельная же модификация Рутокен ЭЦП, поддерживающая ФКН. С тем токеном, что имеется у Вас, оно работать не будет. Такие токены входят в поставку КриптоПро Рутокен CSP.
Насколько я понимаю КриптоПро Рутокен CSP это как раз прослойка между PKCS11 интерфейсом токена и КриптоПро, но вот что-то не заводится.
Нет, это не так. Там отдельный интерфейс на базе PC/SC, PKCS#11 там не задействуется.
Когда генерирую запрос на сертификат, то если использую криптопровайдер "Active Rutoken CSP", то появляется окно с запросом пароля, а если через Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider, то он просит выбрать носитель, но токен выбрать не дает, говорит что устройство недоступно или не отформатировано.
Непонятно почему криптоПро не может обратиться к токену. КриптоПро 3.6.6497.
Правильно, потому что КриптоПро Рутокен CSP работает со специальными токенами, а не с обычными Рутокен ЭЦП.
Rutoken CSP - зачем добавился этот криптопровайдер?
Этот криптопровайдер используется, например для аутентификации в домене Active Directory, он задействует RSA.
КриптоПро CSP не задействует криптографические возможности токенов, а использует их исключительно в качестве ключевых носителей. В данном случае и не обязательно применять Рутокен ЭЦП, достаточно Рутокен S или Рутокен Lite.
Но закрытый ключ на токене неизвлекаемый же должен быть. Каким образом КриптоПро его получает?
КриптоПро CSP не задействует криптографические возможности токенов, а использует их исключительно в качестве ключевых носителей. В данном случае и не обязательно применять Рутокен ЭЦП, достаточно Рутокен S или Рутокен Lite.
Но закрытый ключ на токене неизвлекаемый же должен быть. Каким образом КриптоПро его получает?
КриптоПро CSP генерирует ключи без участия токена и хранит их в специальных файлах-контейнерах, которые находятся на ключевом носителе. Для работы с этими ключами контейнер считывается с носителя и обрабатывается КриптоПро CSP.
КриптоПро Рутокен CSP работает иначе.
Спасибо, теперь все понятно. Видимо мне КриптоПро не подходит, буду пробовать с другими криптопровайдерами.
не специалист и особо в этом не понимаю, но хотелось бы получить консультацию по одному небольшому вопросу:
сертификаты, уже установленные в системе, имеют различные наборы их применения - одни для подписывания почты, другие для идентификации клиента на сервере... там может быть различные сочетания этих политик применения. насколько я понял их следует читать из поля "улучшенный ключ" посредством CertGetEnhancedKeyUsage. (в моем случае требуется получить 1.3.6.1.5.5.7.3.2 - идентификация клиента на сервере). и я вроде это сделал... но тут возникла другая проблема: некоторые сертификаты имеют свойство "все политики применения" - в этом случае поля "улучшенный ключ" не существует и соответственно моя CertGetEnhancedKeyUsage - не работает. каким образом я могу получить это свойство "все политики применения"? какую команду мне следует использовать?
нынешняя последовательность команд такая:
1. CertOpenSystemStore - открываем хранилище, например My
2. CertEnumCertificatesInStore - гоняем по циклу все личные сертификаты
3. CertGetEnhancedKeyUsage - в первый раз получаем размер
4. CertGetEnhancedKeyUsage - во второй раз получаем уже сам массив политик применения
5. CertCloseStore - закрываем хранилище
вот что мне следует использовать вместо второй CertGetEnhancedKeyUsage (пункт 4), если первая CertGetEnhancedKeyUsage (пункт 3) вернет в качестве размера массива 0? или возврат 0 уже и есть доказательство, что сертификат имеет "все политики"? я полагаю если сертификат какой-либо корявый, то CertGetEnhancedKeyUsage тоже вернет 0...
не специалист и особо в этом не понимаю, но хотелось бы получить консультацию по одному небольшому вопросу:
сертификаты, уже установленные в системе, имеют различные наборы их применения - одни для подписывания почты, другие для идентификации клиента на сервере... там может быть различные сочетания этих политик применения. насколько я понял их следует читать из поля "улучшенный ключ" посредством CertGetEnhancedKeyUsage. (в моем случае требуется получить 1.3.6.1.5.5.7.3.2 - идентификация клиента на сервере). и я вроде это сделал... но тут возникла другая проблема: некоторые сертификаты имеют свойство "все политики применения" - в этом случае поля "улучшенный ключ" не существует и соответственно моя CertGetEnhancedKeyUsage - не работает. каким образом я могу получить это свойство "все политики применения"? какую команду мне следует использовать?
нынешняя последовательность команд такая:
1. CertOpenSystemStore - открываем хранилище, например My
2. CertEnumCertificatesInStore - гоняем по циклу все личные сертификаты
3. CertGetEnhancedKeyUsage - в первый раз получаем размер
4. CertGetEnhancedKeyUsage - во второй раз получаем уже сам массив политик применения
5. CertCloseStore - закрываем хранилищевот что мне следует использовать вместо второй CertGetEnhancedKeyUsage (пункт 4), если первая CertGetEnhancedKeyUsage (пункт 3) вернет в качестве размера массива 0? или возврат 0 уже и есть доказательство, что сертификат имеет "все политики"? я полагаю если сертификат какой-либо корявый, то CertGetEnhancedKeyUsage тоже вернет 0...
Здравствуйте!
Какой CSP Вы используете?
эм... а не являясь клиентом подсказку получить нельзя?
эм... а не являясь клиентом подсказку получить нельзя?
Почему же нельзя? Можно.
Вообще говоря, все зависит от требований к системе или политик. То есть Вы можете требовать наличия EKU в сертификате, а сертификаты без EKU вообще не принимать. Решать то есть Вам.
RFC5280:
"Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application."
а тут не я главный. сертификаты уже есть в системе - и на нашем галимом гос портале не принимаются сертификаты, у которых нет свойства "идентификация клиента на сервере" или нет "все политики применения". то есть для успешного входа должно быть или то или то. вот я и хотел бы создать утилиту, которая бы проверяла наличие этих свойств у этих установленных сертификатов и вижжала бы дурным голосом, в случае если они оба отсутствуют. то есть чтоб пользователь знал, что сертификат не рабочий.
вот первое я нашел 1.3.6.1.5.5.7.3.2, получаю в случае если сертификат имеет это свойство, или даже если сертификат имел "все политики", но были насильно помечены лишь некоторые из этих политик через оснастку. а вот если были "все политики" без пометки этих дополнительных галок свойство - тогда я пролетаю. вот мне бы команду, которая бы четко говорила что сертификат имеет "все политики применения"...
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Форум Рутокен → Техническая поддержка разработчиков → Crypto API