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

Уведомление

Icon
Error

16 Страницы«<89101112>»
Опции
К последнему сообщению К первому непрочитанному
Offline ARnikev  
#91 Оставлено : 23 июня 2015 г. 14:45:16(UTC)
ARnikev

Статус: Активный участник

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: afev Перейти к цитате
Стандартно, через панель JCP, закладка "Хранилища ключей и сертификатов".


Алилуя, добавился). Я через keytool пробовал добавлять.

Так, теперь при таком создании ValidationProvider:

Код:

  final CertStore intermediateCertsAndCRLStore = CertStore.getInstance("Collection",
                new CollectionCertStoreParameters(Collections.emptyList()));

  final CertificateValidationProvider validationProvider = new PKIXCertificateValidationProvider(trustStore, false, intermediateCertsAndCRLStore);


ошибок не возникает. Значит ли это что подпись валидна? verifier.verify(signatureElement, null) - возвращает кучу параметров, не понятно, что полезного из них можно вынести.
Offline Евгений Афанасьев  
#92 Оставлено : 23 июня 2015 г. 14:54:50(UTC)
Евгений Афанасьев

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

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,963
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
Если нет исключений, то созданная подпись проверилась. В результате verify - различная служебная информация.
Offline ARnikev  
#93 Оставлено : 23 июня 2015 г. 15:01:12(UTC)
ARnikev

Статус: Активный участник

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: afev Перейти к цитате
Если нет исключений, то созданная подпись проверилась. В результате verify - различная служебная информация.


Эта проверка точно корректна? Странно, то есть ГИС ГМП-шники как-то по другому проверяют ее чтоле? Как мне им аргументировать то, что моя подпись корректна и проблема у них Think .
Offline Евгений Афанасьев  
#94 Оставлено : 23 июня 2015 г. 15:19:47(UTC)
Евгений Афанасьев

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

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,963
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
Попробуйте для начала сделать документ, как тут и проверить (подписать и отправить) - возможно, проблема в положении пространств имен.
Offline ARnikev  
#95 Оставлено : 23 июня 2015 г. 16:04:35(UTC)
ARnikev

Статус: Активный участник

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: afev Перейти к цитате
Попробуйте для начала сделать документ, как тут и проверить (подписать и отправить) - возможно, проблема в положении пространств имен.


А каким образом положение пространства имен может повлиять на корректность подписи сущности?
Offline serchek  
#96 Оставлено : 24 июня 2015 г. 11:20:01(UTC)
serchek

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

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

Подскажите, обязательна ли 2 версия JCP, будет ли работать на 1.0.46?
Offline Евгений Афанасьев  
#97 Оставлено : 24 июня 2015 г. 14:41:11(UTC)
Евгений Афанасьев

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

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,963
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
Автор: ARnikev Перейти к цитате
А каким образом положение пространства имен может повлиять на корректность подписи сущности?

Один и тот же документ с небольшими изменениями в пространствах имен давал разный код обработки.

Автор: serchek Перейти к цитате
Подскажите, обязательна ли 2 версия JCP, будет ли работать на 1.0.46?

В скором времени выложим архив с несколькими примерами, для него будет инструкция (должно работать с JCP 1.0.46 и выше).

Offline ARnikev  
#98 Оставлено : 25 июня 2015 г. 11:04:34(UTC)
ARnikev

Статус: Активный участник

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Вопрос! Перед тем как ставить подпись на сущность сообщение у меня выглядит примерно так:


А когда я выдергиваю из этого сообщения Node сущности для добавления в нее подписи, она выглядит примерно так:


То есть объявления пространств имен наследуются от корневого элемента сообщения GISGMPTransferMsg. А в финальном сообщении, отправляемом в ГИС ГМП, эти объявления пространств имен у дочерних элементов отсутствуют. Отсюда, мне кажется, у меня hash подписи сущности, формируемый при подписи сущности в процессе формирования сообщения, отличается от hash сущности финального сообщения, отправляемого в ГИС ГМП.

Так вот вопрос, это нормально что эти namespaces так наследуются или все таки их не должно быть?

Судя по алгоритму формирования подписи XMLDSIG, описаному здесь http://www.di-mgt.com.au/xmldsig2.html, namespaces родителей как раз распространяются на дочерние элементы, перед формированием хэша. Но тогда как высчитывают хэш сущности ГИС ГМПшники, если когда им приходит сообщение, эти namespace-ы объявлены только у корневого элемента сообщения.

Или я чего-то не понимаю/понимаю не правильно? Может кто пояснить, пожалуйста.

upd. И еще, верификация подписи проходит сразу после ее формирования, т.е. если в проверку подсунуть документ сразу после добавления в него подпись. А вот если подсунуть в проверку финальный документ, который отправляется в ГИС ГМП, то верификация уже не проходит.

Отредактировано пользователем 25 июня 2015 г. 11:15:28(UTC)  | Причина: Не указана

Offline belgampaul  
#99 Оставлено : 25 июня 2015 г. 14:22:03(UTC)
belgampaul

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

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

Поблагодарили: 2 раз в 1 постах
Автор: ARnikev Перейти к цитате
Вопрос! Перед тем как ставить подпись на сущность сообщение у меня выглядит примерно так:


А когда я выдергиваю из этого сообщения Node сущности для добавления в нее подписи, она выглядит примерно так:


То есть объявления пространств имен наследуются от корневого элемента сообщения GISGMPTransferMsg. А в финальном сообщении, отправляемом в ГИС ГМП, эти объявления пространств имен у дочерних элементов отсутствуют. Отсюда, мне кажется, у меня hash подписи сущности, формируемый при подписи сущности в процессе формирования сообщения, отличается от hash сущности финального сообщения, отправляемого в ГИС ГМП.

Так вот вопрос, это нормально что эти namespaces так наследуются или все таки их не должно быть?

Судя по алгоритму формирования подписи XMLDSIG, описаному здесь http://www.di-mgt.com.au/xmldsig2.html, namespaces родителей как раз распространяются на дочерние элементы, перед формированием хэша. Но тогда как высчитывают хэш сущности ГИС ГМПшники, если когда им приходит сообщение, эти namespace-ы объявлены только у корневого элемента сообщения.

Или я чего-то не понимаю/понимаю не правильно? Может кто пояснить, пожалуйста.

upd. И еще, верификация подписи проходит сразу после ее формирования, т.е. если в проверку подсунуть документ сразу после добавления в него подпись. А вот если подсунуть в проверку финальный документ, который отправляется в ГИС ГМП, то верификация уже не проходит.


Абсолютно идентичная картина. Хэшируется локально одна xml (байты взятые из строки, представляющую собой xml фрагмент. Что происходит при проверке и какую xml ГИС ГМП хэширует пока не 100% ясно. Ясно,что хэшируется что-то другое.

Пока жду ответа от службы поддержки ЕТК, может кто-то выложить xml подписываемой сущности?

У моих сущностей есть префикс и namespace указан для этого префикса в корневом элементе сущности. А в soap-пакете namespace, используемый сущностями (FinalPayment, Charge), указан в тэге RequestMessage.

На форматах 1.15.0 xml был одинаков везде (в soap-пакете и в сущности). Там нигде не было неймспейсов.



Offline ARnikev  
#100 Оставлено : 25 июня 2015 г. 14:38:16(UTC)
ARnikev

Статус: Активный участник

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

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

Абсолютно идентичная картина. Хэшируется локально одна xml (байты взятые из строки, представляющую собой xml фрагмент. Что происходит при проверке и какую xml ГИС ГМП хэширует пока не 100% ясно. Ясно,что хэшируется что-то другое.

Пока жду ответа от службы поддержки ЕТК, может кто-то выложить xml подписываемой сущности?

У моих сущностей есть префикс и namespace указан для этого префикса в корневом элементе сущности. А в soap-пакете namespace, используемый сущностями (FinalPayment, Charge), указан в тэге RequestMessage.

На форматах 1.15.0 xml был одинаков везде (в soap-пакете и в сущности). Там нигде не было неймспейсов.



Выше я выкладывал свой подписанный запрос на импорт начисления.

upd. Кстати тоже думаю, что дело как-то касается неймспейсов. Выяснил, что старая подпись XMLDsig тоже перестала работать с сообщением нового формата. Так и не могу понять почему, элемент сущности после ее подписи и после подписи всего сообщения визуально выглядит одинаково. Но при проверке подписи сущности финального документа DigestValue получается совсем другим. Проблема в том, что я неймспейсы руками не проставляю даже, они маршалятся из java классов, которые я с wsdl сервиса получил.

Отредактировано пользователем 25 июня 2015 г. 17:15:34(UTC)  | Причина: Не указана

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest (5)
16 Страницы«<89101112>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.