Статус: Новичок
Группы: Участники
Зарегистрирован: 07.12.2017(UTC)
Сообщений: 9
Сказал(а) «Спасибо»: 2 раз
|
Доюрое всем утро. Попробовала с BC провайдера перейти на JCP для подписания запросов ЕСИА и проверки ответов. Сертификация средств крипто защиты и т.д. Использую JCP хранилище ключей HDImageStore. C загрузкой ключей все Ок. Код: KeyStore clientStore = KeyStore.getInstance("HDImageStore");
clientStore.load(null, null);
clientCertificate = (X509Certificate) clientStore.getCertificate("test");
privateKey = (PrivateKey) clientStore.getKey("test", new char[]{});
Все адекватно, видно что за ключи при дебаге. При формировании подписи запроса auth code ЕСИА получаем (код формирования достался по наследству в BC я делала по-другому). Да и по документации непонятен тип подписи. Но, говорят, когда делали - работало) Код: Signature signature = Signature.getInstance("GOST3411_2012_256withGOST3410_2012_256");
signature.initSign(privateKey);
signature.update(request);
return signature.sign();
Потом использую, как и раньше, Код: Base64.getUrlEncoder().encodeToString(signature)
И получаем ошибку от ЕСИА Код:2024-11-15 14:34:17.682 [http-nio-8081-exec-8] ERROR ru.medlinesoft.esia.EsiaRequest - Parsing error: {"error_description":"ESIA-007053: OAuthErrorEnum.clientSecretWrong","state":"89b5a1b1-a747-441e-9520-8b69da0e7b47","error":"access_denied"}
2024-11-15 14:34:17.682 [http-nio-8081-exec-8] DEBUG ru.medlinesoft.esia.EsiaRequest - Response=[{"error_description":"ESIA-007053: OAuthErrorEnum.clientSecretWrong","state":"89b5a1b1-a747-441e-9520-8b69da0e7b47","error":"access_denied"}]
Ключевой контейнер использовался тестового УЦ КриптоПро. Думала, может, с этим связано. Пробовала реальный контейнер для ревльной ИС - ошибка та же. Изначальный код на BC отличается от вышеуказанного, и он всегла работал на любых типах сертификатов - тестовый УЦ или нет (только для тестовой ЕСИА). Код: try {
CMSTypedData msg = new CMSProcessableByteArray(message);
List certs = Collections.singletonList(clientCertificate);
Store store = new JcaCertStore(certs);
CMSSignedDataGenerator gen = new CMSSignedDataGenerator();
PKCS8EncodedKeySpec privateKeySpec = new PKCS8EncodedKeySpec(clientPrivateKey);
KeyFactory keyFactory = KeyFactory.getInstance("ECGOST3410-2012", provider);
privateKey = keyFactory.generatePrivate(privateKeySpec);
ContentSigner sha1Signer = new JcaContentSignerBuilder("GOST3411WITHECGOST3410-2012-256")
.setProvider(provider)
.build(privateKey);
gen.addSignerInfoGenerator(new JcaSignerInfoGeneratorBuilder(
new JcaDigestCalculatorProviderBuilder()
.setProvider("BC")
.build())
.build(sha1Signer, clientCertificate));
gen.addCertificates(store);
return gen.generate(msg, false).getEncoded();
} catch (IOException | OperatorCreationException | CMSException | CertificateEncodingException |
InvalidKeySpecException | NoSuchAlgorithmException | NoSuchProviderException e) {
log.error("While sign message: ", e);
throw new IllegalStateException("Error " + e.getMessage() + " while sign message");
}
Поэтому вопрос, может, таки оно подписывается оно подругому и с помощью JCP. Полезла смотреть , что же пишут в примерах JCP для создания pkcs7. А там используются объекты той же самой BC библиотеки с вызовом Код: CMSProcessable content = new CMSProcessableByteArray(Configuration.DATA);
CMSSignedData signedData = generator.generate((CMSTypedData) content, true);
Я вообще вошла в ступор. Причем тут JCP ? И верный ли код в PKCS7Example ?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Модератор, Участники Зарегистрирован: 03.12.2018(UTC) Сообщений: 1,190  Сказал(а) «Спасибо»: 100 раз
Поблагодарили: 272 раз в 253 постах
|
Добрый день! JCP / JCSP используется для криптографической математики и обращения к закрытым ключам. BC используется для формирования CMS сообщения. вы приложите подпись которую вы делали раньше в BC. Класс Signature формирует сырое значение подписи. ~ 64 байта, без какой-либо метаинформации кто подписал, что подписал и пр. а ESIA возможно ожидает CMS возможно вам нужен CAdESSignature попробуйте сформировать подпись здесь https://github.com/mshamito/exampleесли подпись пройдет в тестовом контуре, то изучайте код примера |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 07.12.2017(UTC)
Сообщений: 9
Сказал(а) «Спасибо»: 2 раз
|
По итогу код из примера в JCP всего немного отличается от использованного ранее для BC Код: try {
CMSTypedData msg = new CMSProcessableByteArray(message);
List certs = Collections.singletonList(clientCertificate);
Store store = new JcaCertStore(certs);
CMSSignedDataGenerator gen = new CMSSignedDataGenerator();
ContentSigner contentSigner = new GostContentSignerProvider(privateKey, provider);
gen.addSignerInfoGenerator(new JcaSignerInfoGeneratorBuilder(
new GostDigestCalculatorProvider(privateKey, provider))
.build(contentSigner, clientCertificate));
gen.addCertificates(store);
return gen.generate(msg, false).getEncoded();
} catch (Throwable e) {
log.error("While sign message: ", e);
throw new IllegalStateException("Error " + e.getMessage() + " while sign message");
}
Оличается реализация подписанта ContentSigner (GostContentSignerProvider) и класса DigestCalculatorProvider, отвечающего за информацию от подписи - видимо, свзяано с другим алгоритмом шифрования ключа. Работает и для контейнера тестового УЦ для тестовой ЕСИА. Спасибо. Можно закрыть. Кнопки тут не нашла. Отредактировано пользователем 21 ноября 2024 г. 16:19:55(UTC)
| Причина: Не указана
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
