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

Уведомление

Icon
Error

3 Страницы<123>
Опции
К последнему сообщению К первому непрочитанному
Offline ThinkingAnna  
#11 Оставлено : 23 октября 2018 г. 13:05:09(UTC)
ThinkingAnna

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

Группы: Участники
Зарегистрирован: 19.05.2015(UTC)
Сообщений: 41
Женщина
Российская Федерация

Сказала «Спасибо»: 4 раз
Да, ответ от Ростелекома.

Код:
CN="ПАО \"Ростелеком\"", C=RU, ST=78 Санкт-Петербург, L=Санкт-Петербург, STREET="191002, г. Санкт-Петербург, ул. Достоевского д.15", O="ПАО \"Ростелеком\"", OID.1.2.643.100.1=#120D31303237373030313938373637, OID.1.2.643.3.131.1.1=#120C303037373037303439333838, OID.1.2.840.113549.1.9.2=Сертификат ЭП-СМЭВ3.0

Отредактировано пользователем 23 октября 2018 г. 18:57:18(UTC)  | Причина: Не указана

Offline Евгений Афанасьев  
#12 Оставлено : 26 октября 2018 г. 15:41:01(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Необходимо получить информацию, как каноникализируются данные при подписи (образец) и чем она создается.
Offline ThinkingAnna  
#13 Оставлено : 23 ноября 2018 г. 13:28:40(UTC)
ThinkingAnna

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

Группы: Участники
Зарегистрирован: 19.05.2015(UTC)
Сообщений: 41
Женщина
Российская Федерация

Сказала «Спасибо»: 4 раз
Такую информацию Ростелеком не предоставил.
Только лишь ссылаются на свою документацию, где указано следующее:

Формат подписи XMLDSig detached
Расчет хеш-суммы - ГОСТ Р 34.11-94 - http://www.w3.org/2001/04/xmldsig-more#gostr3411
Формирование подписи - ГОСТ Р 34.10-2001 - http://www.w3.org/2001/0...#gostr34102001-gostr3411
Канонизация (для XMLDSig) - Exclusive XML Canonicalization от 18 июля 2002 - http://www.w3.org/2001/10/xml-exc-c14n#
Дополнительная трансформация (для XMLDSig) - Нормализация СМЭВ - urn://smev-gov-ru/xmldsig/transform

Как же так получается, что часть подписей СМЭВ из ответов проходит проверку в КриптоПро, а часть - нет?
Offline Евгений Афанасьев  
#14 Оставлено : 23 ноября 2018 г. 13:35:07(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Здравствуйте.
Еще раз - проблема, скорее всего, в каноникализации, JCP только проверяет хеш (32 байта) и подпись (64 байта), остальное делает, например, xmlsec или любая другая подобная библиотека. Есть ли возможность прикрепить образцы - исходный документ и то, что должно быть получено и проходит проверку где-то (некий тестовый сервис)? <- Имеется в виду проблемный документ (видимо, образец от Ростелеком).
Формат документов может быть разный, потому часть документов проходит, часть нет (каноникализация выполняется иначе).

Отредактировано пользователем 23 ноября 2018 г. 13:37:10(UTC)  | Причина: Не указана

Offline ThinkingAnna  
#15 Оставлено : 23 ноября 2018 г. 13:48:59(UTC)
ThinkingAnna

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

Группы: Участники
Зарегистрирован: 19.05.2015(UTC)
Сообщений: 41
Женщина
Российская Федерация

Сказала «Спасибо»: 4 раз
Поясните, пожалуйста, вы имеете ввиду конкретные примеры xml-документов, которые мы получаем, и в которых подпись проверяется\не проверяется?
Или речь о данных, которые нужно у Ростелекома запрашивать?
Offline Евгений Афанасьев  
#16 Оставлено : 23 ноября 2018 г. 14:14:03(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Для этого конкретного случая у ростелекома есть образцы исходного документа и подписанного, проходящие у них проверку? желательно с промежуточным результатом, где есть каноникализированные данные, которые хешируются и подписываются?

Отредактировано пользователем 23 ноября 2018 г. 14:15:16(UTC)  | Причина: Не указана

Offline two_oceans  
#17 Оставлено : 26 ноября 2018 г. 7:17:26(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Кажется тут диалог зашел в тупик, говорите о немного разных вещах - ошибка не в смэв при проверке подписи в запросе задающего вопрос, а наоборот, вот эти фрагменты это и есть ответ с подписью по версии Ростелекома и по идее эта подпись должна проходить проверку у них самих и ее можно использовать как образец. А задающий вопрос как раз не может ее проверить, так как второй образец возвращает другой хэш после каноникализации.

В документации Ростелокома есть 4 примера по данному дополнительному трансформу, что должно получиться на выходе. Ну за месяц уже можно и вручную построить данный трансформ конкретного образца, сверить с хэшем и убедиться что верное, а что не верное. Ближайшее время как раз планирую этот трансформ реализовать, так что попробую построить и этот конкретный образец.

Полностью согласен в необходимости промежуточного образца (текста после трансформа, от которого считается хэш), это кратчайший путь к решению. В моей реализации C14N одно время была ошибка в том, что один из символов не попадал в список разрешенных в значениях атрибута и потому отсутствовал в канонической форме, соответственно хэш получался другой если в атрибуте присутствовал данный символ. Второй раз во фрагмент не перенеслось пространство имен из "ancestor context" и также вышел другой хэш. По промежуточному образцу эти случаи оказалось очень просто выявить, до этого 2 месяца бодался с проблемой почему одни документы проходят проверку, а другие нет.

Отредактировано пользователем 26 ноября 2018 г. 7:22:27(UTC)  | Причина: Не указана

Offline ThinkingAnna  
#18 Оставлено : 23 января 2019 г. 17:12:41(UTC)
ThinkingAnna

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

Группы: Участники
Зарегистрирован: 19.05.2015(UTC)
Сообщений: 41
Женщина
Российская Федерация

Сказала «Спасибо»: 4 раз
Ждали ответа от техподдержки СМЭВа 3 месяца, в итоге никаких промежуточных этапов трансформации и т.п. они не предоставили, а сослались в очередной раз на свою документацию, что там всё есть.

two_oceans, подскажите, пожалуйста, когда Вы говорите про дополнительный трансформ, вы имеете ввиду SmevTransformSpi, представленный в документации СМЭВа? Вы его дорабатывали?

Offline ThinkingAnna  
#19 Оставлено : 25 января 2019 г. 12:01:50(UTC)
ThinkingAnna

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

Группы: Участники
Зарегистрирован: 19.05.2015(UTC)
Сообщений: 41
Женщина
Российская Федерация

Сказала «Спасибо»: 4 раз
Автор: Евгений Афанасьев Перейти к цитате
Здравствуйте.
Еще раз - проблема, скорее всего, в каноникализации, JCP только проверяет хеш (32 байта) и подпись (64 байта), остальное делает, например, xmlsec или любая другая подобная библиотека.


Поясните еще, пожалуйста по поводу каноникализации.

Вот в документации СМЭВа указано:
Канонизация (для XMLDSig) - Exclusive XML Canonicalization от 18 июля 2002 - http://www.w3.org/2001/10/xml-exc-c14n#
Дополнительная трансформация (для XMLDSig) - Нормализация СМЭВ - urn://smev-gov-ru/xmldsig/transform


Алгоритм дополнительной трансформации предоставляет сам СМЭВ (java-код SmevTransformSpi)
Каноникализация c14n происходит при помощи библиотеке xmlsec, а она вместе с КриптоПро JCP идет же. Т.е. для JCP.2.0 - используется версия xmlsec-1.5.0.
Задавали вопрос, и в СМЭВе говорят, что для работы с их SmevTransformSpi также требуется использовать именно xmlsec-1.5.0.
Тогда как может получиться, что каноникализация выполнятся иначе?

Отредактировано пользователем 25 января 2019 г. 12:02:32(UTC)  | Причина: Не указана

Offline Евгений Афанасьев  
#20 Оставлено : 25 января 2019 г. 12:08:25(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Все операции с XML выполняет xmlsec (разбор, проверки схемы, извлечение узлов и данных, поиск алгоритмов, трансформации и т.д.), затем подает в JCP лишь хеш (32 байта), алгоритм, ключ и подпись (64 байта) для проверки (для подписи - подобным образом). Исключение из xmlsec transform - трансформ СМЭВ.
От коллег (.NET) также поступил документ с каноникализациями: стандартной http://www.w3.org/2001/10/xml-exc-c14n# и СМЭВ (тоже Ростелеком). Одна из подписей не проверяется - не сходится хеш данных (и в Java xmlsec + SmevTransformSpi, и в .NET проекте). Каноникализировались данные согласно публичному SmevTransformSpi. Предположительно, что-то изменилось в алгоритме каноникализации (других причин быть не должно). В процессе выяснения, как проверить подпись.

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

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