Статус: Новичок
Группы: Участники
Зарегистрирован: 23.01.2019(UTC)
Сообщений: 3
|
не появились нормальные средство канонизации?
или скиньте dll от С++
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602  Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Вроде бы нет, есть куча самопальных, реализующих c14n не полностью, то есть выдающих правильные данные для конкретных типов запросов, но для других запросов неизвестно будет ли ответ верным, так как в них могут быть нужны неподдерживаемые реализацией части c14n. Свой вариант реализации при ошибках проверяю программкой c14n.exe от slawv (на основе dotNet 4.5 и выше). С трансформом СМЭВ 3 дела еще хуже - там и алгоритм неподробно описан и тесты не очень точные.
Для формирования текста у меня используется свой вариант представления xml документа (тип-запись с таблицей адресов пространств имен, таблицей префиксов, таблицей тегов, необязательной таблицей атрибутов, необязательной таблицей текстовых узлов и функции для работы с типом), в который можно загрузить документ или фрагмент документа (либо набросать документ с чистого листа), из представления формируется почти-канонический текст документа или фрагмента документа. Потом результат еще раз его перебираю "для надежности" с учетом допустимых символов и т.д. Большая часть времени при подписании и проверке подписи как раз уходит на посимвольный перебор (900-1500 мс на Body, 300-600 мс на SignedInfo). Трансформ СМЭВ 3 на этой основе тоже возможен, примеры прошли проверку, но пока не тестировался на реальных данных.
Тип-запись, а не объект выбран из-за сложности передачи объектов между dll-ками в Delphi/FreePascal. По аналогичным причинам сами строки передаются в типе-записи - длина значения, длина буфера, признак запрета на перевыделение буфера, адрес буфера. Запрет на перевыделение позволяет привязывать тип-запись к shortstring или строкам из блобов сертификата (без символа 0 в конце).
Пока поставил ограничения в 16000 тегов, текстовых узлов и атрибутов, 100 адресов пространств имен и префиксов, 20 Мб на строку. Для большинства документов СМЭВ этого достаточно, но вот для ЕГИССО количество объявлений пространств имен уже превысило сотню, хотя реально используется от силы пять.
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 23.01.2019(UTC)
Сообщений: 3
|
Автор: two_oceans  Вроде бы нет, есть куча самопальных, реализующих c14n не полностью, то есть выдающих правильные данные для конкретных типов запросов, но для других запросов неизвестно будет ли ответ верным, так как в них могут быть нужны неподдерживаемые реализацией части c14n. Свой вариант реализации при ошибках проверяю программкой c14n.exe от slawv (на основе dotNet 4.5 и выше). С трансформом СМЭВ 3 дела еще хуже - там и алгоритм неподробно описан и тесты не очень точные.
использовал uXMLHelper.pas - все работает по крайней мере метод getPrivateLNData
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 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 подпись не верна
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Одна из ошибок очевидна. Во втором файле prParseFilelnlpu.xml у Вас два раза указано одно и то же значение для Id - в теге BODY и в теге ROW. Это нарушает стандарт XML - Id должно иметь уникальное значение в пределах документа. Программы интерпретирующие и проверяющие подпись скорее всего заточены на быстродействие и после того как нашли Body далее предполагают что документ соответвует стандарту и значение больше не встретится, поэтому не будут искать это значение Id в ROW. Очевидно, что значение хэша для Body получится совсем другое чем для Row. Вторая проблема в том, что даже если убрать Id в Body и правильно выберется фрагмент Row у меня все равно выходит другой хэш. Над этим еще подумаю. Отредактировано пользователем 22 января 2020 г. 19:30:43(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 02.12.2014(UTC) Сообщений: 25 Откуда: Воронеж Сказал(а) «Спасибо»: 1 раз
|
Моя ошибка. Пробою разные варианты, подписывать <body>, вместо <row>, пусть хоть фсс не примет, но проверка криптопро пройдет. Не поменял шаблон. Канноникализация c14n.exe не изменяет абсолютно ничего. Проверял на этапе формирования значения digest value через https://www.cryptopro.ru...ades_xmldsig_sample.html - все совпадает. И в первом и во втором файле. Не понятно, почему один файл пропускает, а второй аналогичный нет. Вот правильный неправильный второй файл prParseFilelnlpu.xml (9kb) загружен 3 раз(а).
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Для поправленного файла после каноникализации получаю такой текст с хэшем
5F7D DC5B 8305 1DDF C34F B678 342E D5C4 40DF B9B0 360C A9B3 F998 692F CEBE 2123
X33cW4MFHd/DT7Z4NC7VxEDfubA2DKmz+ZhpL86+ISM=
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 02.12.2014(UTC) Сообщений: 25 Откуда: Воронеж Сказал(а) «Спасибо»: 1 раз
|
Точно, спасибо, получил правильный файл prParseFilelnlpu.xml (18kb) загружен 14 раз(а).Оказывается, каноникализация в uXMLHelper.pas ломала мне его, отключил ее совсем, формирую xml сразу правильной структуры. Теперь при расщифровке ответа от ФСС - плохие данные, хотя с первым файлом ошибок нет, копаем дальше...
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
В первом файле по сути нечего каноникализировать - почти никакие пункты c14n не применяются. Генерировать сразу канонизированный текст конечно можно, но тут может быть конфилкт с некоторыми ИС, которые требуют строго определенного порядка атрибутов, отличного от канонического.
Поэтому я все не решаюсь выкинуть из своей программы самопальный с14n, хотя именно на этот алгоритм уходит большая часть времени и срабатывает вхолостую на моих файлах (у меня копируется куча строк в памяти посимвольно, что мягко говоря "не быстро". Потом перепишу на ассемблере или через MoveMemory). У Вас в файле атрибутов практически нет, поэтому и кажется что можно сгенерировать правильный вариант сразу.
Если будете проверять подпись ответа (как задумывается в любой ИС), то без c14n не обойтись, так как ИС будет слать не обязательно каноничный текст. В новом файле первая подпись проверяется полностью (математически верны SignatureValue и DigestValue), на второй подписи у меня вылетает ошибка. UPD: ошибка была в моей программе. Суть в том, что в данном файле один сертификат включен 2 раза с разными Id. Моя программа определяла, что сертификат уже загружен и не добавляла второй экземпляр с новым Id, потому Id не находился. Исправил, теперь вторая и третья подписи также проверились (математически верны). Отредактировано пользователем 27 января 2020 г. 22:57:39(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 11.01.2020(UTC) Сообщений: 7 Сказал(а) «Спасибо»: 3 раз
|
Всем добрый день! Запрос не проходит проверку, подпись недействительна. Проверяю с помощью https://www.justsign.me/verifyqca/Verify/Окончательно зашел в тупик  Для формирования xml использую описание этой ветки форума и юнит UCryptHelper.pas, в котором для ГОСТ 2012 добавил константу PROV_GOST_2012_256 = 80. В чем дело, не пойму, <body> достаточно прозрачный xml по ссылке (приаттачить к посту не получается): http://seafile.mosgorbti.ru:8000/f/a0bb9a8849/?raw=1 Буду благодарен за любые советы, куда смотреть
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
