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

Уведомление

Icon
Error

8 Страницы«<34567>»
Опции
К последнему сообщению К первому непрочитанному
Offline user100000  
#41 Оставлено : 7 февраля 2019 г. 2:36:08(UTC)
user100000

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

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

не появились нормальные средство канонизации?
или скиньте dll от С++
Offline two_oceans  
#42 Оставлено : 7 февраля 2019 г. 6:43:25(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Вроде бы нет, есть куча самопальных, реализующих c14n не полностью, то есть выдающих правильные данные для конкретных типов запросов, но для других запросов неизвестно будет ли ответ верным, так как в них могут быть нужны неподдерживаемые реализацией части c14n. Свой вариант реализации при ошибках проверяю программкой c14n.exe от slawv (на основе dotNet 4.5 и выше). С трансформом СМЭВ 3 дела еще хуже - там и алгоритм неподробно описан и тесты не очень точные.

Offline user100000  
#43 Оставлено : 8 февраля 2019 г. 12:35:15(UTC)
user100000

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

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

Автор: two_oceans Перейти к цитате
Вроде бы нет, есть куча самопальных, реализующих c14n не полностью, то есть выдающих правильные данные для конкретных типов запросов, но для других запросов неизвестно будет ли ответ верным, так как в них могут быть нужны неподдерживаемые реализацией части c14n. Свой вариант реализации при ошибках проверяю программкой c14n.exe от slawv (на основе dotNet 4.5 и выше). С трансформом СМЭВ 3 дела еще хуже - там и алгоритм неподробно описан и тесты не очень точные.


использовал uXMLHelper.pas - все работает
по крайней мере метод getPrivateLNData
Offline delem  
#44 Оставлено : 20 января 2020 г. 23:00:54(UTC)
delem

Статус: Участник

Группы: Участники
Зарегистрирован: 02.12.2014(UTC)
Сообщений: 25
Российская Федерация
Откуда: Воронеж

Сказал(а) «Спасибо»: 1 раз
Помогите, люди добрые.
Пытаюсь победить сервис ФСС со стороны МО.
Запрос на получение номера ЛН с подписью проходит проверку корректно getNewLNNum.xml (7kb) загружен 17 раз(а).
По аналогии формирую запрос на отправку больничного листа - prParseFilelnlpu.xml (9kb) загружен 11 раз(а).
Проверку не проходит, подпись недействительна.
Что я делаю не так, не могу разобраться.
В первом случае нужно подписывать весь блок <body>, во втором подписывается блок <ROW>, все согласно спецификации.
Для канноникализации используется uXMLHelper.pas, проверял с помощью c14n.exe - изменений никаких в xml не вносит.
Проверяю с помощью https://www.justsign.me/verifyqca/Verify/
Чтобы я не делал - XML подпись не верна
Offline two_oceans  
#45 Оставлено : 22 января 2020 г. 19:16:23(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Одна из ошибок очевидна. Во втором файле prParseFilelnlpu.xml у Вас два раза указано одно и то же значение для Id - в теге BODY и в теге ROW. Это нарушает стандарт XML - Id должно иметь уникальное значение в пределах документа. Программы интерпретирующие и проверяющие подпись скорее всего заточены на быстродействие и после того как нашли Body далее предполагают что документ соответвует стандарту и значение больше не встретится, поэтому не будут искать это значение Id в ROW. Очевидно, что значение хэша для Body получится совсем другое чем для Row.

Вторая проблема в том, что даже если убрать Id в Body и правильно выберется фрагмент Row у меня все равно выходит другой хэш. Над этим еще подумаю.

Отредактировано пользователем 22 января 2020 г. 19:30:43(UTC)  | Причина: Не указана

Offline delem  
#46 Оставлено : 22 января 2020 г. 20:08:43(UTC)
delem

Статус: Участник

Группы: Участники
Зарегистрирован: 02.12.2014(UTC)
Сообщений: 25
Российская Федерация
Откуда: Воронеж

Сказал(а) «Спасибо»: 1 раз
Моя ошибка. Пробою разные варианты, подписывать <body>, вместо <row>, пусть хоть фсс не примет, но проверка криптопро пройдет. Не поменял шаблон. Канноникализация c14n.exe не изменяет абсолютно ничего. Проверял на этапе формирования значения digest value через https://www.cryptopro.ru...ades_xmldsig_sample.html - все совпадает. И в первом и во втором файле. Не понятно, почему один файл пропускает, а второй аналогичный нет.
Вот правильный неправильный второй файл prParseFilelnlpu.xml (9kb) загружен 3 раз(а).
Offline two_oceans  
#47 Оставлено : 22 января 2020 г. 20:27:09(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах

Для поправленного файла после каноникализации получаю такой текст с хэшем
5F7D DC5B 8305 1DDF C34F B678 342E D5C4 40DF B9B0 360C A9B3 F998 692F CEBE 2123
X33cW4MFHd/DT7Z4NC7VxEDfubA2DKmz+ZhpL86+ISM=
Offline delem  
#48 Оставлено : 22 января 2020 г. 20:59:24(UTC)
delem

Статус: Участник

Группы: Участники
Зарегистрирован: 02.12.2014(UTC)
Сообщений: 25
Российская Федерация
Откуда: Воронеж

Сказал(а) «Спасибо»: 1 раз
Точно, спасибо, получил правильный файл prParseFilelnlpu.xml (18kb) загружен 14 раз(а).
Оказывается, каноникализация в uXMLHelper.pas ломала мне его, отключил ее совсем, формирую xml сразу правильной структуры.
Теперь при расщифровке ответа от ФСС - плохие данные, хотя с первым файлом ошибок нет, копаем дальше...
Offline two_oceans  
#49 Оставлено : 24 января 2020 г. 12:26:12(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
В первом файле по сути нечего каноникализировать - почти никакие пункты c14n не применяются.
Генерировать сразу канонизированный текст конечно можно, но тут может быть конфилкт с некоторыми ИС, которые требуют строго определенного порядка атрибутов, отличного от канонического.
Если будете проверять подпись ответа (как задумывается в любой ИС), то без c14n не обойтись, так как ИС будет слать не обязательно каноничный текст.

В новом файле первая подпись проверяется полностью (математически верны SignatureValue и DigestValue), на второй подписи у меня вылетает ошибка.
UPD: ошибка была в моей программе. Суть в том, что в данном файле один сертификат включен 2 раза с разными Id. Моя программа определяла, что сертификат уже загружен и не добавляла второй экземпляр с новым Id, потому Id не находился. Исправил, теперь вторая и третья подписи также проверились (математически верны).

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

Offline DonCossack  
#50 Оставлено : 30 января 2020 г. 15:57:04(UTC)
DonCossack

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

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

Сказал(а) «Спасибо»: 3 раз
Всем добрый день!

Запрос не проходит проверку, подпись недействительна.
Проверяю с помощью https://www.justsign.me/verifyqca/Verify/
Окончательно зашел в тупикBrick wall
Для формирования xml использую описание этой ветки форума и юнит UCryptHelper.pas,
в котором для ГОСТ 2012 добавил константу PROV_GOST_2012_256 = 80.
В чем дело, не пойму, <body> достаточно прозрачный
xml по ссылке (приаттачить к посту не получается):
http://seafile.mosgorbti.ru:8000/f/a0bb9a8849/?raw=1

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