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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline mask.ple  
#1 Оставлено : 21 ноября 2024 г. 10:17:20(UTC)
mask.ple

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

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

Сказал(а) «Спасибо»: 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 ?
Offline Санчир Момолдаев  
#2 Оставлено : 21 ноября 2024 г. 12:31:31(UTC)
Санчир Момолдаев

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

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

Сказал(а) «Спасибо»: 100 раз
Поблагодарили: 272 раз в 253 постах
Добрый день!

JCP / JCSP используется для криптографической математики и обращения к закрытым ключам.
BC используется для формирования CMS сообщения.

вы приложите подпись которую вы делали раньше в BC.
Класс Signature формирует сырое значение подписи. ~ 64 байта, без какой-либо метаинформации кто подписал, что подписал и пр.
а ESIA возможно ожидает CMS

возможно вам нужен CAdESSignature
попробуйте сформировать подпись здесь https://github.com/mshamito/example
если подпись пройдет в тестовом контуре, то изучайте код примера
Техническую поддержку оказываем тут
Наша база знаний
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.