Статус: Участник
Группы: Участники
Зарегистрирован: 14.11.2019(UTC) Сообщений: 11 
|
Доброго времени суток, уважамые форумчане Работаю над задачей по подписыванию XML-конвертов для СМЭВ3 на Java. Заказчик предоставил 6 файлов: header.key masks2.key masks.key name.key primary2.key primary.key. Скажите, пожалуста: 1) правильно ли я понимаю, что для реализации задачи нужен public ключ заказчика и private ключ заказчика. С этими ключами будут работать КриптоПРО JCP и Apache Santuario? 2) 6 файлов .key, которые предоставил заказчик, являются контейнером CryptoPro и из них нужно извлечь public и private ключи? Если так, то есть ли какие-то утилиты для этого? Отредактировано пользователем 14 ноября 2019 г. 20:20:03(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
|
Добрый день. В общем-то извлекать ничего не нужно, JCP понимает контейнер такого формата (папку с именем вида 8 букв-цифр символов, точка, 3 цифры, в которой лежит 6 файлов key), нужно чтобы КриптоПро JCP "увидел" контейнер. В контейнере есть и закрытый и открытый ключи (более точно: СМЭВ не позволит указать "голый" открытый ключ, потребуется весь сертификат, в котором указан открытый ключ).
Куда поместить контейнер чтобы "увидел" зависит от конкретной операционной системы. Про JCP немного затрудняюсь ответить, CSP на windows видит контейнеры в корне несистемных дисков (флешек, например, но оптические диски отпадают, так как что нужен доступ на чтение и запись контейнера), на токенах, в реестре. На *nix нужно скопировать папку-контейнер по определенному пути, путь немного отличается в зависимости от ОС.
После того как контейнер "виден", через панель управления устанавливаете сертификат из контейнера в хранилище (может потребоваться пин-код контейнера; если в контейнере нет сертификата, просите заказчика прислать сертификат отдельным файлом), устанавливаете сертификаты корневого и промежутого удостоверяющих центров (ссылки на скачивание есть в сертификате либо на сайте УЦ либо смотрите на e-trust.gosuslugi.ru, где есть все аккредитованные УЦ), корневой сертификат добавляете в trustAnchor. Детали процедуры есть в соседних темах.
Когда контейнер виден к нему можно обращаться по псевдониму, когда устанолен серификат в хранилище с пометной Private key: Yes то дополнительно можно находить контейнер по реквизитам связанного сертификата (например, отпечаток сертификата или имя субъекта (заказчика)).
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 14.11.2019(UTC) Сообщений: 11
|
Добрый день и спасибо за ответ. Для выполнения задачи я пытаюсь проработать данное решение. Вот ключевой момент: Код:import java.security.cert.X509Certificate;
import java.security.PrivateKey;
import org.apache.xml.security.signature.XMLSignature;
X509Certificate certificate = ....;
PrivateKey privateKey = .....;
XMLSignature sig = new XMLSignature(doc, "", signMethod, canonicalizationMethod);
sig.addKeyInfo(certificate);
sig.sign(privateKey);
Я это к тому, что JCP может и понимает, но с сертификатом работает и апачи. Или я что-то не понимаю. Автор: two_oceans  Добрый день. В общем-то извлекать ничего не нужно, JCP понимает контейнер такого формата (папку с именем вида 8 букв-цифр символов, точка, 3 цифры, в которой лежит 6 файлов key), нужно чтобы КриптоПро JCP "увидел" контейнер. В контейнере есть и закрытый и открытый ключи (более точно: СМЭВ не позволит указать "голый" открытый ключ, потребуется весь сертификат, в котором указан открытый ключ).
Куда поместить контейнер чтобы "увидел" зависит от конкретной операционной системы. Про JCP немного затрудняюсь ответить, CSP на windows видит контейнеры в корне несистемных дисков (флешек, например, но оптические диски отпадают, так как что нужен доступ на чтение и запись контейнера), на токенах, в реестре. На *nix нужно скопировать папку-контейнер по определенному пути, путь немного отличается в зависимости от ОС.
После того как контейнер "виден", через панель управления устанавливаете сертификат из контейнера в хранилище (может потребоваться пин-код контейнера; если в контейнере нет сертификата, просите заказчика прислать сертификат отдельным файлом), устанавливаете сертификаты корневого и промежутого удостоверяющих центров (ссылки на скачивание есть в сертификате либо на сайте УЦ либо смотрите на e-trust.gosuslugi.ru, где есть все аккредитованные УЦ), корневой сертификат добавляете в trustAnchor. Детали процедуры есть в соседних темах.
Когда контейнер виден к нему можно обращаться по псевдониму, когда устанолен серификат в хранилище с пометной Private key: Yes то дополнительно можно находить контейнер по реквизитам связанного сертификата (например, отпечаток сертификата или имя субъекта (заказчика)).
Отредактировано пользователем 15 ноября 2019 г. 9:17:37(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
|
Если я правильно понимаю, privatekey в данном случае не более чем название класса и переменной, реального ключа там нет. Политика КриптоПро в целом не выпускать закрытый ключ из криптопровайдера в незащищенном виде (защита по требованиям ТК26), то есть реально во внешние программы выдается некий временный дескриптор вместо реального закрытого ключа и когда внешней программе нужно допустим подписать этот временный дескриптор попадает обратно в криптопровайдер, криптопровайдер по дескриптору находит реальный закрытый ключ и выполняет подписание. Единственное исключение - экспорт в формат pfx, там выходит реальный закрытый ключ, но он зашифрован так, что его может прочитать КриптоПро и некоторые собранные на коленке программки.
Таким образом, нет смысла сохранять/кэшировать любые "закрытые ключи" полученные из криптопро, так как это все фикция и работает только если внешняя программа использует для подписания тот же криптопровайдер, из которого получен "закрытый ключ"-дескриптор. Через некоторое время или после перезагрузки сохраненный дескриптор будет недействителен и подписать им не получится. Полагаю, именно это и происходит с Apache Santuario, апачи формирует весь костяк подписи, но за вычислением digestvalue signaturevalue внутри вновь обращается к Java, а Java к JCP и дескриптор снова попадает к криптопровайдеру, круг замкнулся. Проверить элементарно - если сможете просмотреть/cохранить содержимое privateKey. В случае дескриптора содержимое будет каждый раз разное.
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 14.11.2019(UTC) Сообщений: 11
|
Спасибо за подробный ответ. Вы пишете Цитата:Если я правильно понимаю, privatekey в данном
случае не более чем название класса и переменной, реального ключа там нет . Но если это так, то как понять следующие две строчки кода из приведенной выше ссылки: Код:// создание внутри узла подписи узла <ds:KeyInfo> информации об
// открытом ключе на основе
// сертификата
sig.addKeyInfo(certificate);
// создание подписи XML-документа
sig.sign(privateKey);
где certificate это класс X509Certificate и privateKey это класс PrivateKey. Таким образом, если я правильно понимаю, мы реально используем в Apache Santuario сертификат и privateKey. Другими словами, что тогда нужно передавать в переменных certificate и privateKey? Отредактировано пользователем 15 ноября 2019 г. 12:47:48(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
|
Автор: PashaTurokME2019 Таким образом, если я правильно понимаю, мы реально используем в
Apache Santuario сертификат и privateKey. Другими словами, что тогда
нужно передавать в переменных certificate и privateKey? Сертификат используете, конечно. Для Вас ничего не меняется, все так же передаете, просто в privateKey вместо реального ключа абстрактная циферка. Смысл в том, что в большей части стека функций данные только передаются дальше по стеку, но в промежуточной функции сами данные не используются. Например, допустим JCP присвоил папке ABCDEFGH.000 номер 1, потом Ваше приложение запрашивает закрытый ключ, но JCP не читает сам ключ, а выдает в приложение экземпляр класса privateKey, содержащий циферку 1. Ваше приложение записывает в переменную экземпляр класса privateKey, содержащий циферку 1. потом передает эту переменную в apache. Заметьте, Ваша программа не знает как работать с циферкой 1 в классе privateKey, просто получает экземпляр класса из одного места, хранит в переменной, передает в другое место, освобождает. Апаче аналогично получает, хранит, передает обратно в JCP. Здесь узкое место - Апаче должно знать куда передать. JCP получает экземпляр класса privateKey, содержащий циферку 1 и знает что это номер в некой внутренней табличке. По этой табличке находит папку-контейнера ABCDEFGH.000 и работает с закрытым ключом в папке. Если непонятно, проведу аналогию с гардеробом в театре: JCP- гардероб/гардеробщица; папка ABCDEFGH.000 с файлами key - пальто; privateKey - номерок; Вы, Ваша программа и апаче - посетители. Чтобы пальто не помялось/не испачкалось/не пропало, сдаете в гардероб и получаете номерок, а когда нужно отдаете номерок и получаете пальто. Естественно если принесете этот номерок в другой гардероб, то пальто не получите.
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 14.11.2019(UTC) Сообщений: 11
|
Я действительно очень благодарен за ваши разъяснения, но, пожалуйста, давайте применим их к конкретному примеру. Есть: 1) файлы header.key masks2.key masks.key name.key primary2.key primary.key. 2) такой код Код:import java.security.cert.X509Certificate;
import java.security.PrivateKey;
import org.apache.xml.security.signature.XMLSignature;
X509Certificate certificate = ???; //ЧТО ТУТ?
PrivateKey privateKey = ???; // И ЧТО ТУТ?
XMLSignature sig = new XMLSignature(doc, "", signMethod, canonicalizationMethod);
sig.addKeyInfo(certificate);
sig.sign(privateKey);
Если я вас правильно понял, то: 1) в certificate мы все равно считываем x509 сертификат? Если так, то как нам выдрать его из файлов .key? 2) в privateKey мы указываем индекс ключа в контейнере КриптоПро. Если так, то как нам его узнать?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,926 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
Здравствуйте. Автор: PashaTurokME2019
X509Certificate certificate = ???; //ЧТО ТУТ?
PrivateKey privateKey = ???; // И ЧТО ТУТ?
Как обычно, нужно обратиться к документации: руководства разработчика и администратора в папке Doc/ЖТЯИ-..-JCP в дистрибутиве. Контейнер копируется в ключевую папку нужного пользователя, далее с помощью KeyStore.getInstance("HDImageStore") по алиасу и паролю он будет доступен. Примеры в samples-sources.jar, раздел JCPxml или xmlSign. Отредактировано пользователем 15 ноября 2019 г. 16:16:52(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
|
Автор: PashaTurokME2019 Если я вас правильно понял, то:
1) в certificate мы все равно считываем x509 сертификат? Если так, то как нам выдрать его из файлов .key?
2) в privateKey мы указываем индекс ключа в контейнере КриптоПро. Если так, то как нам его узнать? 1) Да, равно считываем x509 сертификат. Сертификат хранится в header.key, вместе с другой открытой служебной информацией. Вообще сертификат желательно брать не из файла header.key (так как там может и не быть сертификата), а из отдельного файла или хранилища сертификатов. В общем случае, Вы можете при создании экземпляра хранилища сертификатов указать путь к конкретному файлу сертификата. Однако рекомендуется использовать хранилище сертификатов личное, чтобы было удобнее (ниже) и дальнейшая проверка цепочек сертификатов прошла более гладко. 2) не совсем индекс в контейнере, но не буду цепляться к словам. Как выше ответил коллега из КриптоПро сначала Вам нужно добиться чтобы JCP видел папку с файлами key, при этом сможете получить по алиасу и паролю privateKey. Желательно через панель управления или консоль установить сертификат в хранилище сертификатов. Цель чтобы у сертификата в хранилище стояла строчка Private key: Yes. После этого Вы сможете не привязываться в программе к конкретному алиасу, а найти сертификат в хранилище по отпечатку сертификата или по назначению для СМЭВ3 ЭП-ОВ + огрн, затем из хранилища перейти к контейнеру. Так гораздо удобнее, не нужно исправлять программу при смене сертификата. Отредактировано пользователем 18 ноября 2019 г. 9:27:31(UTC)
| Причина: Не указана
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
