Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.02.2016(UTC)
Сообщений: 60
Сказал(а) «Спасибо»: 18 раз
Поблагодарили: 2 раз в 2 постах
|
Предварительно прочитав предыдущие темы с такой же проблемой (коих много) решения для себя не нашел. Нам передали сертификат 1068.pem полученный по сгенерированному csr и контейнер с приваткой. Я прогнал их методами jcp (2.0.39738) на подпись+шифрование и обратно. Все работало. После нам прислали тестовый файл для расшифровки и снятия подписи. Пробовал расшифровать как кодом из старых примеров, так и cades примерами. Оба выдают одну и ту же ошибку: Код:Exception in thread "main" java.security.InvalidKeyException: Wrapped key is invalid
at ru.CryptoPro.JCP.Key.SecretKeySpec.unwrap(Unknown Source)
at ru.CryptoPro.Crypto.Cipher.GostCoreCipher.engineUnwrap(Unknown Source)
at ru.CryptoPro.Crypto.Cipher.BaseGostCipher.engineUnwrap(Unknown Source)
at javax.crypto.Cipher.unwrap(Cipher.java:2550)
at crypto.CryptoUtil.decrypt2(CryptoUtil.java:488)
at crypto.CryptoUtil.main(CryptoUtil.java:182)
При просмотре cms в разделе данных адресата , вижу блок данных Issuer который совпадает с issuer присланного сертификата. Так же значение поля serialnumber совпадает с именем присланного сертификата. Я понимаю что скорее всего при созданию ключа согласования были использованы некорректные данные и поэтому сейчас я не могу расшифровать симметричный ключ, но как это доказать ? Или причина может быть в другом ?
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 17.11.2019(UTC) Сообщений: 6  Откуда: Moscow Сказал(а) «Спасибо»: 2 раз
|
У меня такое сообщение возникало в случае, когда я пытался расшифровать сообщение при помощи закрытого ключа, не из той ключевой пары, из которой был открытый ключ, использованный для шифрования.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.02.2016(UTC)
Сообщений: 60
Сказал(а) «Спасибо»: 18 раз
Поблагодарили: 2 раз в 2 постах
|
Да я примерно так и думаю. На этапе тестирования сертификата , если я подавал не ту приватку получал такую же ошибку. Вопрос как это можно доказать и ткнуть коллег в то, что зашифровано не правильно.
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
|
Автор: coldplay  При просмотре cms в разделе данных адресата , вижу блок данных Issuer который совпадает с issuer присланного сертификата. Так же значение поля serialnumber совпадает с именем присланного сертификата.
Issuer это УЦ на котором выпущен сертификат, логично что он может совпадать, если один УЦ выдал сертификаты и отправителя и получателя. Сверьте в сертификатах блок Subject или лучше Subject Key Identifier если есть. Уточните, "присланного" имеется в виду в сообщении или присланного в pem. В зашифрованном сообщении должен быть сертификат отправителя, на который будете шифровать ответ. В pem присланном вместе с закрытой частью - по идее Ваш сертификат, то есть получателя. Поэтому если у коллег при шифровании на Ваш сертификат получилось сообщение с сертификатом получателя, его нужно заменить на сертификат отправителя до расшифровки. Удобнее и логичнее если это сделает сам отправитель (вдруг у отправителя несколько сертификатов или получатель работает с несколькими отправителями), но в принципе ничего не мешает это сделать получателю (Вам), если конечно нужный сертификат отправителя у Вас есть. Если для теста замените сертификат в cms на сертификат отправителя (с корректировкой длины тегов asn1) и все заработает, то это наверно будет достаточным доказательством для коллег. Отредактировано пользователем 27 ноября 2019 г. 6:23:03(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.02.2016(UTC)
Сообщений: 60
Сказал(а) «Спасибо»: 18 раз
Поблагодарили: 2 раз в 2 постах
|
Если я Вас правильно понял : при создании ключа согласования я использовал как ту публичную часть что находится контейнере, так и публичную часть из сертификатов отправителя и получателя. Ничего не помогает.
А как можно проверить комплиментарность присланного сертификата и приватного ключа (их прислали раздельно) ? То что я прогнал их через методы encrypt/decrypt служит показателем того что это корректная ключевая пара ?
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
|
Автор: coldplay Если я Вас правильно понял : при создании ключа согласования я использовал как ту публичную часть что находится контейнере, так и публичную часть из сертификатов отправителя и получателя. Ничего не помогает. Странно. Автор: coldplay А как можно проверить комплиментарность присланного сертификата и приватного ключа (их прислали раздельно) ? То что я прогнал их через методы encrypt/decrypt служит показателем того что это корректная ключевая пара ? Как правило в процессе связывания сертификата с контейнером через панель управления КриптоПро CSP, автоматически проверяется совпадение открытых ключей в контейнере и сертификате. При этом соответствие открытого и закрытого ключей в контейнере проверяется при тестировании контейнера. Успех этих двух операций показывает соответствие открытого ключа в сертификате и закрытого в контейнере. В принципе encrypt/decrypt тоже служит подтверждением, но есть нюанс что надо проверять по полной процедуре не выкидывая шагов и на достаточно длинном тексте сообщения.
Нужно понимать, что ключевая пара гост асимметричная, а при шифровании гост используется симметричный алгоритм гост-89, то есть формируется отдельный симметричный ключ, используемый как для encrypt, так и decrypt. При этом есть симметричный ключ согласования и симметричный сессионный ключ. Согласования вырабатывается из двух ассиметричных ключевых пар (отправителя и получателя) - из одной берется открытый ключ, из другой закрытый ключ. Если взять открытый и закрытый из одной пары, то это мало что докажет. Сессионный ключ вообще формируется случайно и не связан с ассиметричной парой. Данные шифруются сессионным ключом, а сессионный ключ шифруется ключом согласования.
Если просто просто прогнать в одном коде encrypt/decrypt, не уничтожая симметричного сессионного ключа, то это ничего не доказывает, потому что сессионный ключ заведомо один и тот же и независим от асимметричной пары и проверится только работа функционала encrypt/decrypt, но не взаимоотношения ключей. Нужно отработать именно восстановление ключа согласования, затем сессионного ключа, а на это как раз и ругается.
Поэтому будет проще проверить пару на подписании и проверке подписи, так как при этом ассиметричная ключевая пара работает напрямую без промежуточных симметричных ключей (то есть при подписании гост, в отличие от зарубежных алгоритмов, не используется шифрование). Можно сымитировать проверку при связывании: сравнить открытый ключ в сертификате и в контейнере. Проблема только в том, что неизвестно точное место в контейнере.
|
 1 пользователь поблагодарил two_oceans за этот пост.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.02.2016(UTC)
Сообщений: 60
Сказал(а) «Спасибо»: 18 раз
Поблагодарили: 2 раз в 2 постах
|
В итоге, проверив ключевую пару (все валидно). Отправили имеющийся набор ключей и контейнер коллегам и они успешно расшифровали свежим криптоармом. Первое что после этого сделали обновили JCP и помогло, ошибка пропала.
Версия до - jcp-2.0.39738 , обновились до jcp-2.0.40502.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
