Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы<12
Опции
К последнему сообщению К первому непрочитанному
Offline zatsepin  
#11 Оставлено : 21 мая 2013 г. 9:00:32(UTC)
zatsepin

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.01.2013(UTC)
Сообщений: 32
Мужчина
Российская Федерация
Откуда: Москва

Сказал «Спасибо»: 2 раз
Прошу прощения за свое невежество, но что это за карты? Можно поподробнее?

И такой вопрос: служба же получает хэндл провайдера с помощью CryptAcquireCertificatePrivateKey() и выполняет подписание документа с помощью CryptCreateHash() + CryptHashData() + CryptSignHash(). Почему для подписания с помощью CryptSignMessage() нужны особые карты аутентификации, если

CryptSignMessage() = CryptAcquireCertificatePrivateKey() + CryptCreateHash() + CryptHashData() + CryptSignHash() + CryptEncodeObject()

UPD: консольное приложение, подписывающее с помощью CryptSignMessage, работает нормально

Отредактировано пользователем 21 мая 2013 г. 10:08:21(UTC)  | Причина: Не указана

Offline alexl  
#12 Оставлено : 21 мая 2013 г. 13:41:10(UTC)
alexl

Статус: Участник

Группы: Участники
Зарегистрирован: 21.05.2013(UTC)
Сообщений: 15
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 2 раз в 2 постах
Из ваших комментариев непонятно - что и в какой конфигурации у вас работает, а что - нет?
Работает ли ваша служба (именно служба) с использованием криптопровайдера "Crypto-Pro HSM Svc CSP" и обычных вызовов CryptoAPI (CryptAcquireCertificatePrivateKey() CryptCreateHash() CryptHashData() CryptSignHash())? Или для проверки вы написали обычное приложение (не службу)?

Может Вам помогут выдержки из документации:

"Криптопровайдер “Crypto-Pro HSM Svc CSP” (тип 75) отличается от криптопровайдера «Crypto-Pro HSM CSP» только тем, что позволяет выводить запросы на ввод пин-кодов для ключей пользователей не на «рабочий стол» рабочей станции пользователя, а на LCD панель ПАКМ. Кроме этого он позволяет организовать обмен между сервером и ПАКМ по более производительному нешифрованному каналу, при условии осуществления однозначной двусторонней аутентификации «сервер<->ПАКМ», нахождении сервера и ПАКМ в одной контролируемой зоне и условии, что используется специальный сертификат ключа доступа, включающий расширение (extended key usage - EKU) «1.2.643.2.2.34.22».
Данный криптопровайдер используется в основном в серверных конфигурациях серверами приложений, работающими в фоновом режиме и не имеющими консоли для вывода сообщений и/или запроса пин-кодов. Он реализован в виде отдельного сервиса ОС Windows, запускаемого при загрузке ОС.
"

"Кроме этого, обращения к криптопровайдерам, работающим с ПАКМ через сервис, в данном случае - «Crypto-Pro HSM Svc CSP» и «Crypto-Pro HSM RSA Svc CSP», могут быть сделаны только пользователями с учетными именами SYSTEM (LocalSystem), NetworkService, пользователями, входящими в группу локальных администраторов компьютера или в группу «Привилегированные пользователи КриптоПро HSM». Группу «Привилегированных пользователей КриптоПро HSM» можно создать вручную и добавить туда, например, учетные имена, под которыми исполняются сервисные приложения (например, пул приложений .NET под управлением Microsoft IIS). Эти же правила действуют при обращении пользователей к любым криптопровайдерам ПАКМ через системный трей, при использовании специального флага в вызовах интерфейса CryptoAPI - CRYPT_MACHINE_KEYSET."

"Администраторам серверов, рекомендуется установить для провайдера 75 типа криптопровайдером по-умолчанию «Crypto-Pro HSM Svc CSP», т.к. некоторые вызовы сервисы Windows делают, используя провайдеры «по умолчанию»."

т.е. для работы с криптопровайдером "... Svc..." нужно в HSM зарегистрировать пользователя с признаком, не помню, точно как он значится, "пользователь-Компьютер" (в Web интерфейсе) или "Is Computer?" в интерфейсе LCD панели. И сформировать для него как обычно ключи и сертификат доступа. В сертификате будет расширение "Администратор сервера" (то, что упомянуто выше - «1.2.643.2.2.34.22»). Плюс ваша служба должна работать под учетной записью, удовлетворяющей вышеописанным условиям.
Offline zatsepin  
#13 Оставлено : 21 мая 2013 г. 13:58:26(UTC)
zatsepin

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.01.2013(UTC)
Сообщений: 32
Мужчина
Российская Федерация
Откуда: Москва

Сказал «Спасибо»: 2 раз
Автор: alexl Перейти к цитате
Из ваших комментариев непонятно - что и в какой конфигурации у вас работает, а что - нет?
Работает ли ваша служба (именно служба) с использованием криптопровайдера "Crypto-Pro HSM Svc CSP" и обычных вызовов CryptoAPI (CryptAcquireCertificatePrivateKey() CryptCreateHash() CryptHashData() CryptSignHash())? Или для проверки вы написали обычное приложение (не службу)?


Наша служба подписывает данные 2 способами:
1. с помощью вызова CryptSignHash
2. с помощью вызова CryptSignMessage. Очень удобно, что эта функция сама еще и заворачивает данные в PKCS#7-envelope.
При этом используется сертификат, ключевой контейнер к которому установлен в провайдере "Crypto-Pro HSM Svc CSP". Явно этот провайдер я нигде не задаю (см. код выше в одном их моих постов), получаю его хэндл по сертификату с помощью вызова CryptAcquireCertificatePrivateKey. А в случае с CryptSignMessage даже этого делать не требуется.
Так вот с CryptSignHash проблем нет, а ошибка при вызове CryptSignMesage послужила поводом для создания этой темы.

Вчера вот этот комментарий
Автор: maxdm Перейти к цитате
А не в службе код работает?

сподвиг меня на написание тестовой утилиты командной строки, которая подписывает данные с помощью CryptSignMesage. Как выяснилось, не из службы код работает. Что только порождает новый вопрос: почему не работает из службы?

Автор: alexl Перейти к цитате

Может Вам помогут выдержки из документации:

"Криптопровайдер “Crypto-Pro HSM Svc CSP” (тип 75) отличается от криптопровайдера «Crypto-Pro HSM CSP» только тем, что позволяет выводить запросы на ввод пин-кодов для ключей пользователей не на «рабочий стол» рабочей станции пользователя, а на LCD панель ПАКМ. Кроме этого он позволяет организовать обмен между сервером и ПАКМ по более производительному нешифрованному каналу, при условии осуществления однозначной двусторонней аутентификации «сервер<->ПАКМ», нахождении сервера и ПАКМ в одной контролируемой зоне и условии, что используется специальный сертификат ключа доступа, включающий расширение (extended key usage - EKU) «1.2.643.2.2.34.22».
Данный криптопровайдер используется в основном в серверных конфигурациях серверами приложений, работающими в фоновом режиме и не имеющими консоли для вывода сообщений и/или запроса пин-кодов. Он реализован в виде отдельного сервиса ОС Windows, запускаемого при загрузке ОС.
"

"Кроме этого, обращения к криптопровайдерам, работающим с ПАКМ через сервис, в данном случае - «Crypto-Pro HSM Svc CSP» и «Crypto-Pro HSM RSA Svc CSP», могут быть сделаны только пользователями с учетными именами SYSTEM (LocalSystem), NetworkService, пользователями, входящими в группу локальных администраторов компьютера или в группу «Привилегированные пользователи КриптоПро HSM». Группу «Привилегированных пользователей КриптоПро HSM» можно создать вручную и добавить туда, например, учетные имена, под которыми исполняются сервисные приложения (например, пул приложений .NET под управлением Microsoft IIS). Эти же правила действуют при обращении пользователей к любым криптопровайдерам ПАКМ через системный трей, при использовании специального флага в вызовах интерфейса CryptoAPI - CRYPT_MACHINE_KEYSET."

"Администраторам серверов, рекомендуется установить для провайдера 75 типа криптопровайдером по-умолчанию «Crypto-Pro HSM Svc CSP», т.к. некоторые вызовы сервисы Windows делают, используя провайдеры «по умолчанию»."

т.е. для работы с криптопровайдером "... Svc..." нужно в HSM зарегистрировать пользователя с признаком, не помню, точно как он значится, "пользователь-Компьютер" (в Web интерфейсе) или "Is Computer?" в интерфейсе LCD панели. И сформировать для него как обычно ключи и сертификат доступа. В сертификате будет расширение "Администратор сервера" (то, что упомянуто выше - «1.2.643.2.2.34.22»). Плюс ваша служба должна работать под учетной записью, удовлетворяющей вышеописанным условиям.


Наша служба работает под учетной записью LocalSystem. Мы не являемся владельцами HSM, поэтому регистрировать/создавать на нем ничего не можем. Насколько я понимаю, он настроен согласно документации, большая часть функционала нашего решения отрабатывает корректно. Проблема только с вызовом CryptSignMessage.

Только мне до сих пор не ясно, чем так принципиально отличаются вызовы CryptSignHash и CryptoSignMessage?

Буду очень признателен за разъяснения, или хотя бы какой-нибудь workaround
Offline alexl  
#14 Оставлено : 21 мая 2013 г. 14:46:03(UTC)
alexl

Статус: Участник

Группы: Участники
Зарегистрирован: 21.05.2013(UTC)
Сообщений: 15
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 2 раз в 2 постах
Попробуйте сделать криптопровйдер «Crypto-Pro HSM Svc CSP» провайдером по-умолчанию для 75 типа. Реализация CryptSignMessage помимо указанных вызовов может включать другие обращения... к провайдеру по-умолчанию
thanks 1 пользователь поблагодарил alexl за этот пост.
zatsepin оставлено 21.05.2013(UTC)
Offline zatsepin  
#15 Оставлено : 21 мая 2013 г. 14:49:52(UTC)
zatsepin

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.01.2013(UTC)
Сообщений: 32
Мужчина
Российская Федерация
Откуда: Москва

Сказал «Спасибо»: 2 раз
А разве реализация не оперирует хэндлом провайдера, который получается по сертификату подписанта?
Offline zatsepin  
#16 Оставлено : 21 мая 2013 г. 15:06:52(UTC)
zatsepin

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.01.2013(UTC)
Сообщений: 32
Мужчина
Российская Федерация
Откуда: Москва

Сказал «Спасибо»: 2 раз
Автор: alexl Перейти к цитате
Попробуйте сделать криптопровайдер «Crypto-Pro HSM Svc CSP» провайдером по-умолчанию для 75 типа. Реализация CryptSignMessage помимо указанных вызовов может включать другие обращения... к провайдеру по-умолчанию


Спасибо! Это помогло!

UPD: Работает, если в качестве провайдера по умолчанию стоит "CryptoPro HSM Svc CSP" или "Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider". И не работает, если в качестве провайдера по умолчанию стоит "CryptoPro HSM CSP"

Еще раз спасибо за помощь!

Отредактировано пользователем 21 мая 2013 г. 15:18:20(UTC)  | Причина: Не указана

Offline alexl  
#17 Оставлено : 21 мая 2013 г. 17:28:40(UTC)
alexl

Статус: Участник

Группы: Участники
Зарегистрирован: 21.05.2013(UTC)
Сообщений: 15
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 2 раз в 2 постах
Реализация CryptSignMessage под Windows - это реализация Microsoft. Что там они делают - ? скорее всего исследуют OID-ы в сертификате и по ним пытаются определить тип провайдера. А получив тип возможно пытаются открыть контекст по типу (без имени провайдера). Для чего - ?

Криптопровайдеры "CryptoPro HSM Svc CSP" или "Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider" доступны из сервисов. Криптопровайдер "CryptoPro HSM CSP" - реализован через hsmtray, который запускается в пользовательской сессии (может быть и не одной), а приложение-сервис (оно работает в нулевой windows сессии) просто не знает как к нему обратиться, к какой windows сессии пользователя... и т.п.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
2 Страницы<12
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.