Статус: Участник
Группы: Участники
Зарегистрирован: 13.04.2017(UTC) Сообщений: 14  Сказал(а) «Спасибо»: 2 раз
|
Здравствуйте. Речь о проверке подписи с использованием сертификата без закрытого ключа и, соответственно, контейнера ключей (т.е. CryptAcquireCertificatePrivateKey, возвращающий дескриптор правильного провайдера, не работает). Нужно вызывать CryptImportPublicKeyInfo, где уже указывается провайдер + считать хеш с его использованием. Как в таком случае правильно выбрать тип провайдера и указать правильные ALG_ID, алгоритм хэширования и параметры? Сейчас существует некая непроверенная логика (поскольку новый гост пока не используется) вроде: Код: if (pubKeyAlgo == "1.2.643.2.2.19")
setParams(CALG_GR3411, szOID_CP_GOST_R3411, szOID_GostR3411_94_CryptoProParamSet);
else if (pubKeyAlgo == "1.2.643.7.1.1.1.1")
setParams(CALG_GR3411_2012_256, szOID_CP_GOST_R3411_12_256, "");
else if (pubKeyAlgo == "1.2.643.7.1.1.1.2")
setParams(CALG_GR3411_2012_512, szOID_CP_GOST_R3411_12_512, "");
(аналогично выбирается тип открываемого провайдера - 75, 80 и 81 соответственно), но что-то терзают сомнения, правильно ли так делать. С параметрами хеширования вообще непонятно. То их нужно указывать функцией CryptSetHashParam, то не нужно, то явное указание вообще всё ломает (для 80 и 81 провайдера). Пожалуйста, проясните взаимосвязи. Спасибо.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,390  Откуда: КРИПТО-ПРО Сказал «Спасибо»: 37 раз
Поблагодарили: 714 раз в 619 постах
|
У Стрибога нет параметров - указывать их не нужно. Мы сознательно возвращаем ошибку при их установке, чтобы пользователи задумались над тем, что делают.
Провайдер для проверки подписи можно указывать любой из 75\80\81.
Конкретный выбор криптопровайдера важен только для генерации ключа. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 13.04.2017(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз
|
Для кодированной подписи CryptVerifyDetachedMessageSignature не предполагает указание провайдера.
А если подпись не кодированная, то любой провайдер не подойдет, поскольку нужно посчитать правильно хеш для CryptVerifySignature,
а дефолтные алгоритмы у провайдеров разные. Опять же, в CryptCreateHash необходимо указывать (знать) ALG_ID (откуда?).
А из знания ALG_ID следует знание о том, нужно ли уточнять параметры хеша. Причем непонятно, как это последнее знание обобщить
(хотя бы в контексте гостовых алгоритмов). И то, если бы оно было.. или если бы можно было получить возможные параметры
какими-то функциями апи, чтобы понять, существуют вариации настроек или нет.
В минимуме хотелось бы узнать правильный способ определения ALG_ID при вызове CryptVerifySignature и oid алгоритма хеширования
для инициализации CRYPT_SIGN_MESSAGE_PARA.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,390 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 37 раз
Поблагодарили: 714 раз в 619 постах
|
Так правильный способ и описан в первом сообщении.
Любой провайдер из трёх перечисленных. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 13.04.2017(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз
|
То есть нет никаких более очевидных способов создать объект хеширования (для проверки подписи, т.е. в контексте сертификата),
кроме как проанализировать алгоритм открытого ключа и выбрать подходящий ALG_ID самостоятельно вот такой условной логикой?!
А если у алгоритма хеширования могут быть различные настройки, то как определять их, чтобы сгенерировать хеш так же, как подписант?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,390 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 37 раз
Поблагодарили: 714 раз в 619 постах
|
Если известен алгоритм подписи, то нужно использовать конечно же его.
Если указаны алгоритм и параметры хэширования - то задавать.
Вы же не пишете, про какой формат подписи идёт речь.
|
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Автор: parihaaraka  А если у алгоритма хеширования могут быть различные настройки, то как определять их, чтобы сгенерировать хеш так же, как подписант? В сертификате рядом с информацией об открытом ключе также указываются 3 ОИДа, ОИД параметров алгоритма хэширования среди них. По нему однозначно определяются и алгоритм и парамсет. Его нужно читать и если не совпадает с параметром по умолчанию (текущий параметр получается по hp_oid), то устанавливать явным образом. Кроме того, параметры хэширования могут быть переданы и без сертификата. Например, в подписи xml предусмотрен такой способ. В стандарте xmldsig под тегами Digest и SignatureMethod могут быть указаны дополнительные теги с оидами параметров, в том числе хэширования. Если дополнительные теги не указаны, то алгоритм определяется по атрибуту Algorithm и используются параметры по умолчанию, прописанные в стандарте. Правда, раскопать мне это удалось только в просроченном черновике RFC. Интересно, есть ли действующий стандарт, поправляющий xmldsig под ГОСТ? Возможность указания отдельно связана с тем, что в xmldsig возможно передавать ключи (ключи ГОСТ в том числе) вместо сертификата. Практически, пока мне ни разу не пришлось менять параметры хэширования - для гост-2001 (точнее 34.11-94) парараметры КриптоПро стали фактическим стандартом и менять просто нет необходимости (но на всякий случай проверяю). Хэш гост-2012 еще плотно не тестировал, но по вышесказанному - используется без параметров. К слову, если хотите сделать программу универсальной, не привязанной к КриптоПро CSP 4.0, то учтите, что для 34.11-94 alg_id у других криптопровайдеров более-менее совпадают (проверял на типе 90), но на гост-2012 alg_id совсем другие.
|
 1 пользователь поблагодарил two_oceans за этот пост.
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 13.04.2017(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз
|
> Если указаны алгоритм и параметры хэширования
Они не указаны. Всё, что есть - сертификат.
Я ведь написал выше. Простой пример - СМЭВ. Получили soap-конверт, достали запчасти: сертификат, хеши, знания о том, что именно подписано, и сами подписи.
Подписи там не кодированные (внутри не asn.1). Обычная реализация проверки подписей предполагает вписанные прямо в коде алгоритмы и настройки хеша.
Но если бы это была часть разнообразного трафика, где заранее в документации не прописаны алгоритмы, то какая должна быть логика проверки? Если
предполагать возможность существования любых подписей любыми ключами? Хочется написать обобщенное решение, которое смогло бы работать и при смене
ГОСТа, и, как вариант, при использовании не ГОСТа (хотя вроде и не надо...). Т.е. есть сертификат подписанта с открытым ключом - и всё.
Нужно сделать хеши и сверить с имеющимися (помимо проверки подписи). Смотрим на открытый ключ (без тела):
OBJECT IDENTIFIER 1.2.643.2.2.19 gostPublicKey(GOST R 34.10-2001 (ECC) public key)
SEQUENCE(2 elem)
OBJECT IDENTIFIER 1.2.643.2.2.36.0 cryptoProSignXA(CryptoPro ell.curve XA for GOST R 34.11-2001)
OBJECT IDENTIFIER 1.2.643.2.2.30.1 cryptoProDigestA(CryptoPro digest params for GOST R 34.11-94)
или
OBJECT IDENTIFIER 1.2.643.7.1.1.1.2
SEQUENCE(2 elem)
OBJECT IDENTIFIER 1.2.643.7.1.2.1.2.1
OBJECT IDENTIFIER 1.2.643.7.1.1.2.3
Здесь мы имеем готовые параметры для функции CryptSetHashParam, НО, как выяснилось, иногда эти параметры запрещено использовать. Это раз.
А еще нужен ALG_ID в CryptCreateHash. Как на него выйти?
*И почему-то только для формирования кодированной подписи нужен алгоритм хеширования в CRYPT_SIGN_MESSAGE_PARA. Как выйти на него?
Понятно, что можно собрать информацию и втупую прописать зависимости (как в первом посте), но неужели это и есть правильный путь?
Вопрос именно в этом.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,390 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 37 раз
Поблагодарили: 714 раз в 619 постах
|
В СМЭВ (xmldsig) указаны все алгоритмы хэширования в uri.
А использование нестандартных узлов замены для хэша - уникальная ситуация и не думаю, что Вы с ней столкнётесь.
|
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 13.04.2017(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз
|
В uri алгоритмы указаны, но использовать их можно только таким же перебором, как в первом посте.
Есть ли смысл указывать их, если можно определять эти настройки по алгоритму открытого ключа?
Или, все же, это может не сработать (а значит, и вся первоначальная идея)?
*Непонятно, почему есть отдельно ALG_ID и алгоритм в виде oid для CRYPT_SIGN_MESSAGE_PARA.
Почему по-разному задается способ хеширования?
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
