Esia 007002 ошибка

Статус: Новичок

Группы: Участники

Зарегистрирован: 31.05.2022(UTC)
Сообщений: 1

Здравствуйте.
В версии ЕСИА 2.90 депрекейтнули эндпоинт для получения кода авторизации /aas/oauth2/ac. Новая версия: /aas/oauth2/v2/ac.

Изменилось описание формирования параметра client_secret.

До версии 2.90:

Версия 2.90:

В версии <2.90 с «подпись запроса в формате PKCS#7 detached signature» разобрались, работает.

В версии 2.90 неясно, что такое «подписать полученную строку с использованием алгоритма подписания data hash с использованием механизмов КриптоПРО CSP»?
Формулировка весьма расплывчатая, на мой взгляд.
Должен ли измениться код формирования подписи?
«data hash» — это название алгоритма?
Есть ли рабочий java-код под эту задачу?

Использование прежнего java-кода формирования подписи параметра client_secret (с учётом прочих обновлений параметров, описанных в инструкции) приводит к ошибке «ESIA-007005: The client is not authorized to request an access token using this method.», что по моему опыту соответствует некорректно сформированному client_secret.

На данный момент сгенерированный url получения кода авторизации выглядит следующим образом:

Отредактировано пользователем 31 мая 2022 г. 22:15:29(UTC)
 | Причина: Не указана

Статус: Новичок

Группы: Участники

Зарегистрирован: 06.07.2022(UTC)
Сообщений: 1

У вас получилось что-нибудь с получением кода авторизации? Тоже зависли на этом моменте и не знаем куда двигаться. Поддержка Минцифры только пересылает отрывки из методички.

Дополнение от 07.07.2022:

после формирования подписи с помощью GOST3411_2012_256withGOST3410_2012_256 получили корректный client_secret

Библиотеки на языке Golang: https://github.com/Theo730/gogost
Описание: http://www.gogost.cypherpunks.ru/

Отредактировано пользователем 7 июля 2022 г. 13:01:22(UTC)
 | Причина: Не указана

Статус: Эксперт

Группы: Участники

Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,598

Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 389 раз в 364 постах

Добрый день. Сначала конечно замечание, что не шифрования, а подписания, так как в сообщениях выше процитированы места, где ясно говорится «подпись», «подписать».
1) Если перевести идентификаторы на человекопонятный язык, то это ГОСТ-2012 (256 и 512 бит), ГОСТ-2001. Насчет актуальности последнего весьма сомнительно, так как сертификаты гост-2001 уже должны были все закончиться. Для вышеуказанных идентификаторов нужно на подписание передавать сами данные, а не вычисленный заранее хэш.
2) Если речь про PKCS#7, то там нет проблемы с порядком байтов, все определено в стандарте. Если же речь про RawSignature, то стандарт не определяет порядок байт, может понадобится «переворачивать/отзеркалить» значение хэша и/или подписи (первый байт с последним, второй с предпоследним и т.д) до кодирования BASE64, так как указанные идентификаторы без слова «CryptoPro», что подразумевает порядок байт Big Endian. Обычно достаточно перевернуть значение подписи. В то же время есть идентификаторы гост-2012 со словом «CryptoPro», которые подразумевает порядок байт Little Endian — то есть переворотов не нужно.
3) Важно также не забывать, что URL Safe Base64 не то же самое, что BASE64, нужно заменить ряд символов, имеющих специальное значение в URL.

Что же до указанной ссылки на библиотеку Го, похоже на несертифицированное решение с самостоятельной реализацией криптографических примитивов. Для тестов с тестовыми ключами конечно никто Вам ничего особо не скажет. Используя же несертифицированное решение с гитхаба в продакшене с «боевыми» ключами, Вы принимаете на себя риски возможных штрафов за неправильное обращение со СКЗИ и ключевой информацией. Будьте бдительны, не все работающие решения можно использовать по закону.

Статус: Новичок

Группы: Участники

Зарегистрирован: 23.08.2022(UTC)
Сообщений: 1

Я правильно понимаю, что сначала вычисляем hash с помощью алгоритма GOST3411_2012_256, а потом подписываем вычисленное значение алгоритмом GOST3410_2012_256?

Или нужно как-то иначе использовать механизмы КриптоПро CSP?

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

Группы: Участники

Зарегистрирован: 19.10.2022(UTC)
Сообщений: 10

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 2 раз в 2 постах

Вот рабочий код на Java для формирования client_secret с использованием крипто-провайдера BouncyCastle:

PrivateKey privateKey = ...;
String joinedString = String.join("", clientId, scope, timeStamp, state, redirectUri);
Signature signer = Signature.getInstance("GOST3411WITHECGOST3410-2012-256", new BouncyCastleProvider());
signer.initSign(privateKey);
signer.update(joinedString.getBytes());
signature = signer.sign();
String clientSecret = Base64.getUrlEncoder().encodeToString(signature);

Отредактировано пользователем 19 октября 2022 г. 13:53:54(UTC)
 | Причина: Не указана

оставлено 11.11.2022(UTC)

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

Группы: Участники

Зарегистрирован: 25.11.2020(UTC)
Сообщений: 13

Откуда: NSK

Сказал(а) «Спасибо»: 2 раз

Статус: Новичок

Группы: Участники

Зарегистрирован: 28.03.2023(UTC)
Сообщений: 1

Коллеги!

А у кого-нибудь получилось с использованием cryptcp -signf подписать секрет клиента для второй версии API(v2/ac) ЕСИА?

Вот так мы сейчас создаем подпись для ЕСИА(код на go):

command := exec.Command(s.cmd, «-signf»,
«-der»,
«-strict»,
«-cert»,
«-hashalg», s.hashAlgOID,
«-detached»,
«-thumbprint», s.thumbprint,
«-pin», s.containerPIN,
filename)

С первой версией все прекрасно работает, с v2 не хочет работать. ЕСИА возвращает ошибку ESIA-007053: OAuthErrorEnum.clientSecretWrong