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

Уведомление

Icon
Error

2 Страницы12>
Опции
К последнему сообщению К первому непрочитанному
Offline KDA  
#1 Оставлено : 14 ноября 2017 г. 16:37:10(UTC)
KDA

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

Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 42

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 6 раз в 6 постах
Добрый день. Хотелось бы прояснить по работе к контестами без физических контейнеров

Сценарий 1.
CryptAcquireContext(&hProv, 0, CP_GR3410_2012_PROV, PROV_GOST_2012_256, CRYPT_VERIFYCONTEXT); //OK
CryptGenKey(hProv, CALG_GR3410_12_256, CRYPT_EXPORTABLE, &hNewKey); //OK
CryptGetUserKey(hProv, AT_SIGNATURE, &hKey); //NTE_NO_KEY

В документации - ключ предназначен для ЭЦП. CryptSignHash тоже возвращает NTE_NO_KEY
Собственно, как этим ключом воспользоваться для ЭЦП?

Сценарий 2. Более актуальный
Имеем pfx файл, полученный экспортом сертификата с закрытым ключем из оснастки Windows

Импорт без физических контейнеров - ок.
HCERTSTORE hStore = PFXImportCertStore(blob, pwd, PKCS12_NO_PERSIST_KEY);

Запрос ключа работает
CryptAcquireCertificatePrivateKey(cert_ctx, CRYPT_ACQUIRE_USE_PROV_INFO_FLAG, &hProv, &dwKeySpec, ...); //OK
CryptGetUserKey(hProv, dwKeySpec, &hKey); //OK
...
Подпись работает
CryptSignHash(hProv, dwKeySpec,....); //OK

CryptGetKeyParam(hKey, KP_NOTAFTER, ...) //NTE_BAD_KEY

В документации - вызов допустим для ключей AT_SIGNATURE/AT_KEYEXCHANGE. Тут он есть
Каким образом здесь организован контроль сроков действия ключей со стороны CSP и как получить эту информацию?


Сценарий 3.
На конктект провайдера первый CryptGetProvParam(hProv, PP_ENUM_CONTAINER_EXTENSION, ... CRYPT_FIRST)
падает с NTE_BAD_FLAGS

На нормальный контейнер все ОК.


Собственно, что здесь баги, а что - особенности пока без документации?
Вопросы весьма актуальны в свете очередной сертификации нашего ПО на корректность встраивания/СКЗИ

Offline Андрей Писарев  
#2 Оставлено : 14 ноября 2017 г. 19:15:55(UTC)
Андрей *

Статус: Сотрудник

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

Сказал «Спасибо»: 494 раз
Поблагодарили: 2035 раз в 1579 постах
Здравствуйте.

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

Сценарий 1.
CryptAcquireContext(&hProv, 0, CP_GR3410_2012_PROV, PROV_GOST_2012_256, CRYPT_VERIFYCONTEXT); //OK
CryptGenKey(hProv, CALG_GR3410_12_256, CRYPT_EXPORTABLE, &hNewKey); //OK
CryptGetUserKey(hProv, AT_SIGNATURE, &hKey); //NTE_NO_KEY




А откуда известно, что там AT_SIGNATURE?
Что выдает запрос ключа: AT_KEYEXCHANGE?
Техническую поддержку оказываем тут
Наша база знаний
Offline Максим Коллегин  
#3 Оставлено : 14 ноября 2017 г. 20:43:26(UTC)
Максим Коллегин

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,375
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 32 раз
Поблагодарили: 704 раз в 613 постах
В первом кейсе генерится эфемеральный ключ, подписать на нём нельзя. Зачем хочется это сделать, если не секрет?

При импорте PrivateKey блоба в VerifyContext (это происходит при импорте pfx) подписывать на временном ключе можно.

То, что не работает KP_NOTAFTER - скорее всего ошибка, и либо уже исправлено, либо будет исправлено в ближайшем билде (при импорте действия срок появляется) - какую сборку тестировали?

Третий сценарий не понял. А в контрольной панели тестирование проходит нормально?

Отредактировано пользователем 14 ноября 2017 г. 20:45:01(UTC)  | Причина: Не указана

Знания в базе знаний, поддержка в техподдержке
Offline KDA  
#4 Оставлено : 15 ноября 2017 г. 15:01:24(UTC)
KDA

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

Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 42

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 6 раз в 6 постах
Автор: Андрей * Перейти к цитате
Здравствуйте.

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

Сценарий 1.
CryptAcquireContext(&hProv, 0, CP_GR3410_2012_PROV, PROV_GOST_2012_256, CRYPT_VERIFYCONTEXT); //OK
CryptGenKey(hProv, CALG_GR3410_12_256, CRYPT_EXPORTABLE, &hNewKey); //OK
CryptGetUserKey(hProv, AT_SIGNATURE, &hKey); //NTE_NO_KEY




А откуда известно, что там AT_SIGNATURE?
Что выдает запрос ключа: AT_KEYEXCHANGE?



Предполагается из документации: http://cpdn.cryptopro.ru...16c4534cf13fc150f29.html
Функция CPGenKey
AlgId: CALG_GR3410_12_256 Производится ключевая пара согласно ГОСТ Р 34.10-2012 с длиной ключа подписи 256 бит. Предназначена для ЭЦП. Эквивалентна AT_SIGNATURE, но в ключевой контейнер не заносится.

Запрос AT_KEYEXCHANGE возвращает то же самое. Но по документации предполагался именно AT_SIGNATURE.
Кстати, генерация с алгоритмом AT_SIGNATURE в таком контексте дает NTE_FAIL.
Offline KDA  
#5 Оставлено : 15 ноября 2017 г. 15:14:33(UTC)
KDA

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

Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 42

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 6 раз в 6 постах
Автор: maxdm Перейти к цитате
В первом кейсе генерится эфемеральный ключ, подписать на нём нельзя. Зачем хочется это сделать, если не секрет?

При импорте PrivateKey блоба в VerifyContext (это происходит при импорте pfx) подписывать на временном ключе можно.

То, что не работает KP_NOTAFTER - скорее всего ошибка, и либо уже исправлено, либо будет исправлено в ближайшем билде (при импорте действия срок появляется) - какую сборку тестировали?

Третий сценарий не понял. А в контрольной панели тестирование проходит нормально?


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

По pfx - сборки 4.0.9842 (R2) и 4.0.9929(R3)

По третьему сценарию - это временные контексты из сценариев 1 и 2. Их, кажется, нельзя тестировать в контрольной панели.
Просто была попытка по загруженному Pfx самостоятельно посмотреть расширения по срокам действия/политикам ключа. Как минимум, код ошибки не соответствует документации, с остальным вопрос - должно работать или нет.
Offline Максим Коллегин  
#6 Оставлено : 15 ноября 2017 г. 23:42:51(UTC)
Максим Коллегин

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,375
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 32 раз
Поблагодарили: 704 раз в 613 постах
3. Вы хотите сделать что-то лунное - получаете расширение контейнера без контейнера.
Срок действия без контейнера не определен, но в будущих версиях будем возвращать -1 в таких случаях.
По 1) - скорее всего ошибка в документации.
Мне все равно не понятна задача электронной подписи без ключа.
Если напишите, зачем это необходимо - мы подумаем, как это можно будет реализовать.
Знания в базе знаний, поддержка в техподдержке
Offline KDA  
#7 Оставлено : 16 ноября 2017 г. 15:22:17(UTC)
KDA

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

Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 42

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 6 раз в 6 постах
Автор: maxdm Перейти к цитате
3. Вы хотите сделать что-то лунное - получаете расширение контейнера без контейнера.

Я хочу не астрологии, а более вменяемого кода ошибки. Потому что с флагами-то тут точно все в порядке. Хотя не вижу принципиальных проблем для возврата пустого списка расширений без физического контейнера.
Но тут у каждого своя логика.
Microsoft CSP в аналогичной ситуации возвращает NTE_BAD_TYPE, например.

Цитата:

Срок действия без контейнера не определен, но в будущих версиях будем возвращать -1 в таких случаях.

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


Цитата:

Мне все равно не понятна задача электронной подписи без ключа.

Ключ здесь есть. "Предназначен для ЭЦП" и "эквивалентна AT_SIGNATURE". Блоб экспортируется с алгоритмом, соответствующим долговременному ключу.
Спецификации RFC/TK26, да и самого ГОСТ, вроде тоже не указывают, что подпись можно делать только с помощью данных, предварительно записанных в долговременную память.

Теперь посмотрим, что у нас подразумевает генерация AT_SIGNATURE:
- Генерация с алгоритмом, определяемым типом CSP
- Запись в контейнер
- Доступность для функций, принимающих на вход спецификатор (СryptGetUserKey, CryptSignHash и т.д)

Что документировано здесь:
- Алгоритм задается явно
- Записи в контейнер нет

В чем тогда еще "эквивалентность"? Поясните, пожалуйста.

Для справки, Microsoft CSP вполне себе позволяет генерацию AT_SIGNATURE/AT_KEYEXCHANGE в контестах, открытых с флагом CRYPT_VERIFYCONTEXT

Задача простая: иметь единоообразный код (работа произвольным контекстом в терминах CryptGetUserKey и подобных),
экспорт ключа ЭП в свое собственное хранилище.
А то разные воркэраунды под разные версии КриптоПро плодятся и множатся.
Помнится, были сборки Крипто-Про, которые при явном задании алгоритма (а не AT_SIGNATURE) тоже в контейнер ключи писали.

Отредактировано пользователем 16 ноября 2017 г. 15:23:10(UTC)  | Причина: Не указана

Offline Максим Коллегин  
#8 Оставлено : 16 ноября 2017 г. 21:46:02(UTC)
Максим Коллегин

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,375
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 32 раз
Поблагодарили: 704 раз в 613 постах
Флаги AcquireContext имеются в виду.
В документацию конечно внесём.
По поводу работы с временными ключами - в 4.0 поведение изменить мы уже не сможем. Про 5.0 - обсудим в ближайшее время.
Знания в базе знаний, поддержка в техподдержке
Offline Максим Коллегин  
#9 Оставлено : 16 ноября 2017 г. 22:07:45(UTC)
Максим Коллегин

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,375
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 32 раз
Поблагодарили: 704 раз в 613 постах
Но есть один нюанс: при подписи без ключевого контейнера - необходимо обеспечить уникальность k. Сейчас это обеспечивается сохранением состояния ПДСЧ в ключевом контейнере. При работе без контейнера этот момент нужно будет серьезно переработать или требовать наличия сертифицированного физического ДСЧ.
Знания в базе знаний, поддержка в техподдержке
Offline KDA  
#10 Оставлено : 17 ноября 2017 г. 14:27:08(UTC)
KDA

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

Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 42

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 6 раз в 6 постах
Если не секрет, а каким образом это сейчас обеспечивается при экспорте/импорте формата pkcs12? Особенно импорт с флагом PKCS12_NO_PERSIST_KEY?
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы12>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.